Wednesday, December 31, 2008

IE Vol 1: Carrier Supporting Carrier - MPLS Enabled Complete

Nothing too fancy about this lab. About the only note worth mentioning is next-hop-self is required on the PE routers iBGP session. This is because the CE link is not advertised in OSPF, therefore the P routers don't have reachability to them. But, since we have the loopback interfaces in OSPF, the P routers have those links in their routing tables and build MPLS labels for them.

IE Vol 1: Inter-AS MPLS VPNs with Multihop MP-eBGP Complete

This was very similar to the last lab, with one fundamental difference. This time, the BGP AS border routers no longer participate in vpnv4. Instead, the MPLS PE routers peer directly via ipv4 and vpnv4.

A very interesting problem occurs because we're using MPLS VPNs. Remember that a MPLS VPN packet contains an IGP label and a VPN label. The situation encountered is as follows:

................AS1. AS2 ..............
C---PE----P-----P-----P-----P----PE---C
.................^... ^..................
..............BGP-ASBRs.............

The 2 BGP-ASBR P routers do not run MPLS on their neighboring interfaces. If we were not running VPN, the BGP-ABR router could simply pop the label, do an IP lookup, and then forward the packet to the next router.

But since we use VPN, when the BGP-ABR router pops the label, it now has a VPN label which it does not understand. Therefore, it must drop the packet.

To alleviate this, we need to ensure a single label switched path exists across both AS's.

This is accomplished with the neighbor send-label command.

Tuesday, December 30, 2008

IE Vol 1: Inter-AS MPLS VPNs with MP-eBGP for VPNv4 Exchange Complete

Wow, that title sure is a mouthful. This lab seriously threw me for a loop. No matter what I did, my provider PE routers would not load the vpnv4 routes advertised by the customer PE routers.

After playing with enough debug commands, I finally came across the following:

R2#debug ip bgp vpnv4 uni upd
*Dec 31 03:03:41.943: BGP(2): 150.1.3.3 rcvd UPDATE w/ attr: nexthop 150.1.3.3, origin ?, localpref 100, metric 0, extended community RT:1:100
*Dec 31 03:03:41.943: BGP(2): 150.1.3.3 rcvd 1:100:10.1.37.0/24 -- DENIED due to: extended community not supported;

Huh? What does it mean extended community not supported?

As it turns out, extended communities, by default, are not accepted from eBGP peers. This is the first lab that I've tried to exchange vpnv4 routes across eBGP, so it's the first time I've run into this.

The command to enable extended communities across eBGP peers is no bgp default route-target filter. The details can be found here.

IE Vol 1: Inter-AS MPLS VPNs with Back-to-Back VRF Complete

Things are starting to get really complex. I was stumped a few times on this one and had to look at the answers. Most of my problem involved incorrect assumptions about bgp vpnv4.

Prior to this lab, the general rule has been to only peer bgp vpnv4 with PE routers. But in this lab, two separate bgp ASs are peering separate vrf's over separate interfaces. Rather than two providers sharing routes over vpnv4, they split them over the interfaces as ipv4 neighbors.

So it actually ends up with each provider's edge router actually acting like a CE router and a PE router at the same time. Each provider is each other's customer.

I guess this is what back-to-back VRF means. Rather than sharing the vpnv4 information across bgp, we strip the rd information out, but dedicate a subinterface for each vrf. Then on the other side of the link, the router loads the routes back into bgp and reconstructs the vpnv4 routes.

Why do it this way? One reason seems to make sense--what if you need to carry MPLS VPNs across separate providers but each provider is using different route descriptors? This would allow each provider to load their own rd when the routes are imported. If vpnv4 routes were shared, rd's would need to be consistent across the entire path.

Monday, December 29, 2008

IE Vol 1: Carrier Supporting Carrier - IP Only

In this lab, the goal is to segment one AS (something like a tier-2 carrier) with another AS (a tier-1 carrier). It's quite interesting how this ends up working out. The Tier-1 carrier becomes the P network, and the tier-2 carrier becomes the C network. iBGP relationships can still be formed by CE routers across the P network, since as far as the CE routers are concerned, the routes are all being learned via OSPF. The entire separate AS is completely transparent to the C network.

There really wasn't anything particularly challenging about this lab, there was just a lot going on. It's definitely required to build each piece step by step and verify along the way. A simple missing mpls adjacency, ospf neighbor, or bgp next-hop-self missing could make troubleshooting really difficult.

The mpls verification was quite interesting. On the PE routers, a separate MPLS adjancency is actually formed inside of the vrf. To check this, the commands sh mpls ldp neigh vrf VPN_A and sh mpls for vrf VPN_A are required.

Aside from that, I had to go back and do a couple of redistribute connected's into bgp. This was required so that I could ping from the outgoing interface rather than the loopback of the true customer routers.

IE Vol 1: VPNv4 Route Reflection Complete

This was an interesting lab that took a heck of a lot of time to just reconfigure the topology.

Essentially, the configuration ends up with two separate route reflectors--one for ipv4 routes and one for vpnv4 routes. Amazingly, no real complex configuration is required. There's no need to mess with clusters or anything like that. Instead, simply configuring the route-reflector-clients under vpnv4 instead of directly under the bgp process takes care of it.

I did run into two issues due to simple mistakes. First, one of my PE routers showed all MPLS labels as being untagged. This was due to me forgetting to turn on cef on one of the P routers.

Second, one of my CE routers was not learning any RIP routes. This issue actually threw me for a loop for a bit. It turned out that on the PE router I didn't set RIP to version 2 under the appropriate address-family. By default, rip sends version 2 and receives versions 1 and 2. But when version 2 is specified, rip only sends and receives version 2.

Since the PE router did not specify, it received the version 2 routes from the CE router and entered them into the routing table. It also redistributed its bgp routes into RIP and sent them as version 1.

Since the CE router specified version 2, it ignored the version 1 routes sent by the PE router.

Wednesday, December 24, 2008

IE Vol 1 OSPF Domain-id complete

This was another interesting lab. Typically in MPLS, redistribution is done from OSPF to BGP and back to OSPF in order to connect OSPF together across the P network. Because of the redistribution, OSPF sees the remote sites as External (LSA type 5) networks.

But since these remote sites are likely to be within one company's control, having them marked external may not be the best option. Instead, the domain-id can be used on the PE router under the ospf process. When the PE router advertises the ospf route to the CE router, it looks at the domain ids of both routes. If they match, the ospf route is advertised as an inter-area (IA) route instead of an External route.

This seems like it would be important for a couple of reasons. IA routes are always preferred over E routes. Also, E routes are not advertised into stubby areas, while IA summaries are. In more complex scenerios with a mix of nssa areas and redistribution, a company may prefer to use its provider's MPLS network rather than another non-MPLS link. The domain-id allows for this much easier than filtering routes from the edges.

Tuesday, December 23, 2008

IE Vol 1 OSPF Sham Links Complete

This was an interesting lab on two levels. It was the first time I have configured isis and ospf sham links are an interesting subject.

I was really amazed at how easy it is to configure a simple instance of isis. Just configure a net address and throw isis on the interfaces, optionally set the interface type, and it's complete. No issues there.

OSPF sham links, on the other hand, I found to be a a much more complicated subject. Its purpose is to deal with a customer that has non-MPLS links neighboring via OSPF, yet the customer still wants to route this traffic over MPLS.

Once these OSPF routes hit BGP, they are seen as iBGP routes, which as an AD of 200, as opposed to the OSPF AD of 110. This means if the prefix-length and default AD is the same, the OSPF route is going to be entered into the routing table.

To prevent this, an ospf sham link must be created. This is configured by setting up an additional loopback interface on the PE router and adding it to the customer VRF. Next, these loopbacks need to be redistributed into the bgp ipv4 vrf. Once the loopbacks are reachable to each other via the P network, under the ospf vrf process, enter area 0 sham-link source-ip dest-ip. This, somewhat similar to a virtual-link, creates a logical link between the newly created loopback interfaces. Then, the path is seen via ospf rather than bgp and the MPLS route can be preferred over the customer link.

Monday, December 22, 2008

Study Plan

The following is a rough draft of my SP Lab study plan. I don't have a date set yet so this will become more precise once I do. I plan (so far) to use Internetwork Expert for all of my studying. The basic timeline that was successful last time was 1 month of studying one practice lab per week, and then two months of two practice labs per week leading up to the actual lab.

Already completed: Volume 1 MPLS VPN labs.

Week of 12/21: Remaining Volume 1 MPLS labs.
Week of 12/28: Volume 1 Multilcast labs.

1/4: Volume II lab 1
1/11: Volume II lab 2
1/18: Volume II lab 3
1/25: Volume II lab 4
1/31: Volume II lab 5

2/1: Volume II lab 6
2/7: Volume II lab 7
2/8: Volume II lab 8
2/14: R&S Graded Mock lab
2/15: Volume II lab 9
2/21: CCIE Assessor R&S
2/22: Volume II lab 10
2/28: R&S Graded mock lab
2/29: Repeat of one of the Volume II labs

So this puts me taking the lab sometime in March. Hopefully I can find a date around there. I'm still waiting for my exam to clear the CCIE site so I can see what dates are available. I should know within the next day or two.

SP Materials, and lack thereof

I don't have a lab date setup yet, but hypothetically I'd like to take the lab around April. I know from R&S that I need a good three months to prepare.

There are only 10 full Volume II labs in the Internetwork Expert labs, as opposed to 20 in the R&S curriculum. I wouldn't expect this to be too much of a problem since I really only went through 10 of the full workbook labs for R&S anyway.

That leaves 3 main gaps to cover. In R&S I relied heavily on a one week bootcamp, about 5 graded mock labs, and the CCIE Assessor.

In actuality, those three pieces were the most helpful to get me ready to tackle the CCIE itself, rather than specifically R&S material. So I think I can still take a couple of graded R&S mock labs to ensure my accuracy is ok. I'm hoping I won't need a bootcamp this time around, but I'm open to it depending on how the studying goes.

SP Community

Thanks to everyone for their positive comments over the past week. It's nice to see there are few others out there working on SP as well. Sometimes this feels like the loneliest CCIE since there's an absence of graded mock labs, groupstudy forum, and not many posts in the other forums out there. The rest of the non-R&S CCIE world seems to be working on Security or Voice for their second.

Good luck to Route Target as well, who will be taking his SP lab in February.

Passed CCIE SP Written 350-029

I thought I'd take a stab at the SP Written before year's end. I've heard rumors that this exam wasn't nearly as nasty as the R&S Written.

There was the standard 10-20% of questions that were just plain ridiculously hard. Aside from those, I'd say easily 50% of the exam is pretty basic to anyone with a CCNP and CCIP level of knowledge. Heck, quite a few of the questions were more on the CCNA level to be honest.

So that leaves the remaining 30%. They were difficult but strangely it was pretty easy to weed out the wrong answers. The usual questions such as, "Pick the best 4 out of 6". I'd have no idea about the 4 to pick. But two obviously didn't belong since they were part of a different technology altogether.

As far as written exams go, I'd rank them as follows in order of difficulty:

BGP+MPLS: 10
R&S Written: 9
Remaining CCNP and CCIP exams: 8
SP Written: 7
CCNA: 5

That's how I feel. If you know the CCIP and CCNP material, 50% the questions on the SP Written exam are actually easier than what's found in the professional level. So if you can deductively eliminate incorrect answers and get lucky on a few of the other half of the exam, you should be able to pass it.

And now it's time to begin studying for the lab. I'll put a study plan together in the coming days. I'm hoping to shoot for my first attempt in April or May.

Friday, December 19, 2008

From CCIE R&S to CCIP

While it's still fresh in my mind, I thought I'd put a little guide together for those who already have their R&S CCIE and want to work on the CCIP. One of the struggles I've found is there is very little study material out there geared directly toward the CCIP, aside of course from the exams that overlap with CCNP and CCVP.

I'd recommend taking the exams in the following order:
1. BSCI. If you already have a CCNP, you may have already passed the exam. I do find it strange that a CCIE R&S doesn't waive this requirement. I last passed the BSCI in 2002, so I needed to retake this. The only topic in the exam that is not really covered by R&S is IS-IS. This is a topic on the service provider blueprint, so take the opportunity to get some studying done on it.

2. QoS. You should already be pretty familiar with QoS from the CCIE R&S.

3. For the brave, go for BGP+MPLS. I will definitely say I found this to be one of the toughest exams I've taken. It's certainly up there on the CCIE Written calibur of exams. There are lots of very tricky questions that you have to pay close attention to. There's also an abundance of questions from obscure topics that I would have expected to be a small part of the exam.

4. Otherwise, go for BGP separately from MPLS. I did take the BGP exam as well, and found it to be MUCH simpler than BGP+MPLS. Of course having a CCIE R&S means you should already know BGP pretty well. Now I never did take the MPLS exam, so I cannot comment on it.

For BGP+MPLS, the following resources are very helpful. Make sure to know them inside and out. There were some more obscure topics that I could only find covered in the these links.

MPLS Virtual Private Network Enhancements
BGP Case Studies
Cisco Express Forwarding Overview
Configuring Cisco Express Forwarding
BGP: Frequently Asked Questions
MPLS Configuration on Cisco IOS Software (Book)

Also make sure to spend some time on MPLS technology labs from your vendor of choice. Internetwork Expert has a great price on an SP bundle, which includes Class on Demand.

Good luck!

RFC 3439

I'm normally not a big fan of reading RFCs. Aside from the funnier ones I've provided links for to the right, I tend to find them way to dry and academic. Short of pulling some information out, such as the meaning of a particular field in TCP, I almost never even look at RFCs.

In the SP Written blueprint, Cisco specifically mentions RFC 3439. Amazingly, I'm finding it very readable and interesting.

http://www.rfc-archive.org/getrfc.php?rfc=3439

Thursday, December 18, 2008

Finally! CCIP Complete!

I finally managed to pass BGP+MPLS tonight. I figured out most of the trick questions and brushed up on the topics I needed to and finally got through this. It took me a whopping 5 attempts to pass! I've never needed more than 2 attempts to pass an exam before. Not even the R&S CCIE lab itself.

Now it's time to start working on the SP Written. One look at the blueprint and I'll need to focus on the following topics:

  • Service Provder Network General
  • ATM, POS, DPT/RPR
  • ISIS
  • High Availability
  • High End Product

Friday, December 12, 2008

Holding Pattern

Since it's taken me so long to get the CCIP, I went ahead and took 350-001 again to recertify my CCIE. I just squeaked by, but I didn't study at all for the exam. I still find that exam particularly annoying.

So I've been back an forth trying to decide if I want to even bother with the CCIP or not. I think I'm going to take another stab at either the MPLS exam or the BGP+MPLS exam. I just don't feel up to studing for the SP written yet.

Tuesday, November 18, 2008

MPLS VPNs with BGP Site-Of-Origin Complete

This was an interesting lab that took a bit of research for me to understand what was happening.

When we use as-override, the intention is to work around the loop prevention mechanism of eBGP so that a CE router will accept a route from another CE router with the same AS.

But sometimes that loop prevention mechanism is still needed. This typically occurs when two CE routers have a backdoor (i.e. non-PE) connection to each other, in addition to the PE connection.

Such a connection can create a routing loop when used in conjunction with as-override. This is because the PE router strips the originating AS and then advertises the route back out to the other CE. This CE router has no idea that this is the same route it is learning from its backdoor neighbor, so a routing loop can be created.

To prevent this, the site-of-origin (soo) extended community can be set via a route-map. No filtering is required, everything happens automatically once it is set. When a PE router learns a route with an SOO set, it will not advertise another route with the same SOO set to its CE neighbor.

The catch to this is that the backdoor route cannot be used as a redundant connetion to the other CE router. If the MPLS connection drops, traffic cannot be rerouted dynamically through the other CE router.

To check if SOO is set on the PE router, use sh ip bgp vpnv4 all X.X.X.X

Monday, November 17, 2008

MPLS VPNs and VRF Export Map Complete

The Export Map allows much more granular control over which networks get advertised to which vpnv4 prefixes. There's a great example at http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_e1.html#wp1012602

I learned a bit more about the order of operations of MPLS during this exercise. I mistakenly forgot to import the route-targets on R3. During troubleshooting, I noticed that the routes that were supposed to be imported were not present in sh ip bgp vpnv4 all. Apparently this table does not get populated until the specific route-targets are imported by a vrf.

Sunday, November 16, 2008

MPLS VPNs with Extranets Complete

I was pretty surprised I got this one right the first time. It's simply a matter of getting the route target imports and exports correct.

I think I'm still a little fuzzy on the transition from an IP address to a route descriptor to a route-target, and how they all interoperate with routing protocols and redistribution.

This lab did help to tie it together somewhat. I suppose my understanding is that it goes something like this:

When an interface is setup for vrf forwarding, it is no longer part of the global routing table. Instead, the router performs a lookup to get more details about the vrf that the interface is an instance of. It goes to the vrf configuration and finds the route descriptor, which is uses to relate this interface to IGPs and ipv4 BGP. Then, it sends out a BGP vpnv4 route for each export target. These export targets get flooded throughout the BGP vpnv4 peers, which should encompass all PE routers. Finally, with these vpnv4 routes flooded, the import route-target is used to load the remote vpnv4 routes into the particular vrf routing table.

Saturday, November 15, 2008

Central Service MPLS VPNs Complete

I found this lab really neat. They had me go back to RIP as the PE-CE routing protocol, which was nice to help me commit the syntax to memory. The trick this time was I had to create 4 different vrf's and allow the R5 vrf to act as a central services VPN. This acts kind of like a promiscuous port in switching terminology: all the other vrfs can access it, but individual vrfs are isolated from each other.

The interesting part here is I finally got to play around with import/export route targets. It actually worked pretty intuitively. Under the R5 vrf, I configured it to import and export all of the other route-targets. Once RIP propagated about 30 seconds later, everything magically worked. That was all there was to it. Way too easy.

The solutions guide specified to import R5 into the other 3 vrfs, instead of exporting to the other vrfs from R5. It appears to be 6 one way and a half dozen the other, but I do wonder if there is a standard to try to import when possible. Sort of like in an access-list it's a good idea to set it up inbound. This makes sense on an access-list because filtering it ingress saves processor time and bandwidth utilization.

MPLS VPNs with eBGP Complete

Two interesting pieces to this lab.

First, when a route comes in from a CE router, it has its AS listed in the AS path. The route crosses the core to the far end PE router, where it gets advertised out with the original AS number along with the PE AS number. The the CE router receives this, it drops the route because it sees its own AS number in the path.

To prevent this, the neighbor as-override command is placed on the PE ipv4 address-family. This command advertises the routes to the CE router with only the PE's AS in the AS path. This way the CE router does not drop the routes coming from the other PE router.

The second issue I ran into is that I needed to redistribute connected into the PE bgp address-families. I was a little confused as to exactly why, even though the CE routers could only ping each other if this was present. So I removed it to see what was happening.

Here's the BGP table with the redistribute connected removed from the R6-SW2 address-family:
Rack1R3#sh ip bgp vpnv4 all
BGP table version is 74, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:57 (default for vrf R5-SW1)
*>i10.1.5.0/24 150.1.4.4 0 100 0 100 i
*> 10.1.7.0/24 10.1.37.7 0 0 100 i
*> 10.1.37.0/24 0.0.0.0 0 32768 ?
*>i10.1.45.0/24 150.1.4.4 0 100 0 ?
Route Distinguisher: 1:68 (default for vrf R6-SW2)
*>i10.1.6.0/24 150.1.4.4 0 100 0 200 i
*> 10.1.8.0/24 10.1.38.8 0 0 200 i
*>i10.1.46.0/24 150.1.4.4 0 100 0 ?

Note there is not a route to 10.1.38.0/24 in BGP. But who cares? And then it dawned on me.

When we ping, the router uses the IP from the outgoing interface, unless a different ip is specified during the ping. Sure enough, pings work fine when sourced by the loopback address, since that is contained in the BGP table. But when the ping is sourced from the outgoing interface, BGP doesn't have a route to it.

This wasn't an issue with RIP, OSPF, or EIGRP, because IGPs automatically add the interface that the protocol is running on to the routing table. But BGP does not do this. It only adds routes specifically injected via the network command, or routes redistributed into BGP.

To prove the theory, I'm going to use a network command for the connected interface rather than redistributing connected. I typically prefer not to redistribute so I can avoid ugly RIB tables.

Sure enough, that did the trick. And note how the origin is internal for the network'ed route as opposed to unknown for the redistributed route.

*>i10.1.38.0/24 150.1.3.3 0 100 0 i
*> 10.1.46.0/24 0.0.0.0 0 32768 ?

MPLS VPNs with EIGRP Complete

Nothing too challenging with this lab. EIGRP is configured similarly to RIP where address families are named under the EIGRP process. What is interesting is that different autonomous system numbers are used for each EIGRP vrf.

Friday, November 14, 2008

MPLS VPNs with OSPF Complete

I'm getting faster and faster at these. OSPF was pretty straightforward, there was probably just one oddity I found.

When redistributing BGP into OSPF, there's no need to mention the VRF name since OSPF can figure that out by the OSPF VRF.

However, when redistributing OSPF into BGP, you do have to explicitly put the VRF name in addition to the process number. It would seem to me that BGP should be able to figure out the VRF name from the address family.

MPLS VPNs with RIPv2 Complete

Wow, I actually am getting better at this MPLS stuff. When moving from static routes to RIP, the complexity increases greatly. It's a good thing RIP itself is such a simple protocol.

So the main difference here is that address-families must be created under global RIP process. All the configuration is then applied under each RIP address-family. I found it very interesting at first that none of the redistribution in BGP or RIP requires the naming of the address-family. The router is smart enough to keep track of all this based on the address-family it is under, and the vrf assigned to the interface.

For example, when I first configured RIP, I was concerned about the network statement. Being that multiple interfaces fell under 10.0.0.0, I thought all of the interfaces would be advertised into the particular address-family of RIP and that I'd have to use passive-interface or filtering to block them. Nope. The router only advertises the interfaces that have the vrf of the applicable address-family. Makes perfect sense, and makes my life a lot easier.

I also got stuck for a bit because I couldn't find the RIP routes getting distributed into BGP. Turns out I needed to use sh ip bgp vpnv4 vrf instead of sh ip bgp. Makes sense, as I needed to see the routing table of the vrf instance, not the global bgp table.

I'm feeling a lot better about MPLS VPNs today, and have a better understanding the significance of route descriptors as well.

Thursday, November 13, 2008

MPLS VPNs with Static Routing Complete

Points to remember when configuring MPLS VPNs:

First create the vrf and associate the rd and import/export rules
Next assign the interfaces to the vrf and reapply IP addresses
Then configure the BGP vpnv4 address family, activating the other PE router and send both communities
Also under BGP, configure the ipv4 vrf address family, redistributing as appropriate
Finally, configure any necessary ip route vrf's.

Use show ip route vrf *, show ip bgp vpnv4 all, and ping vrf to verify connectivity

I really need to commit to memory when to use the vpnv4 address family and when to use the ipv4 vrf address family. It makes sense conceptually. The vpnv4 family includes the extended communities, and basically acts as a type of tunnel between PE routers. Then, each ipv4 vrf is like a pvc inside of that tunnel. Finally, the vrf itself describes what routes get leaked between each individual vrf.

The router uses rd's to keep track of vrf's. We use the vrf name to associate the vrf with interfaces and bgp.

The router uses rt's to advertise vrf's across vpnv4 through the use of extended communities.

SP Volume I Basic MPLS Complete

The biggest challenge here was in getting Dynamips up and running and configured. Fortunately, IE has a great guide which saved me a lot of work. I first tried to run it in Windows, but the performance was too poor. So I switched to Linux, and I can get the Vol I equipment up and running just fine.

The Basic MPLS lab was just what it says. Just needed to throw OSPF and BGP on a few routers and then put MPLS on the core. It was a nice exercise just to watch the pings propagate even though the core routers don't have a route to the final destination.

I had two mistakes in my configuration that I was able to correct pretty quicly. First, I missed mpls ip on one of the interfaces. Because it was missing, some of my hops were untagged in the mpls forwarding table. Simply checking the mpls neighbors at each router pointed me to the issue pretty quickly.

The second mistake was that I didn't put next-hop-self on the PE routers. This is necessary because the core needs a route to the next BGP hop, just not to the final destination. By deafult, iBGP does not update the next-hop and leaves it as the first eBGP hop.

Monday, November 10, 2008

My New MPLS Strategy

Now the other 3 CCIP exams are out of the way and it's time to focus on MPLS. I usually pick up networking technologies pretty easily, but there are a few in the past I have had a hard time with. One of those, in particular, was BGP.

This is one of my favorite responses to one of my groupstudy posts when I was struggling with BGP and another member made a humerous analogy to learning BGP from a book.

I have to agree with that to a certain extent. I was completely clueless on BGP a few years ago, eventhough I read Internet Routing Architectures cover to cover at least twice. It wasn't until I performed enough complex redistribution labs and worked with it in the real world before I got my arms around it.

I now seem to be having the same struggles with MPLS. I have the fundamentals more or less memorized, but I don't really understand the how's and why's of what's going on. I think that is what's keeping me from getting through the MPLS exam.

So rather than continue to brute force the exam, I've decided to pick up the InternetworkExpert Service Provider material. I'm hopeful reviewing their Class on Demand and working through their techonology labs will help to get me up to speed.

Thursday, November 6, 2008

A Little Redemption

I passed the BGP exam today with a lot of room to spare. There were a lot more questions on this than on the BGP+MPLS exam, with a lower passing score to boot. A few of the questions were tricky, but for the most part they were pretty much what I was expecting.

So on the bright side, I now know I was doing pretty well on the BGP portion of the BGP+MPLS exam. The problem with this is I was doing a heck of a lot worse on the MPLS portion. If my scores were similar, that would mean I must have been getting approximately 50% on the MPLS portion of the combined exam.

Now it's time to focus on MPLS. I've tried just reading books and that doesn't seem to help it sink in. I ran into the same thing with BGP a few years back and just didn't "get it" until I did enough labs. It may be time for the same approach with MPLS.

Wednesday, November 5, 2008

The (Alleged) Recession's Impact on CCIE Numbers

With the performance of the stock market and layoff announcements rising, even though it's not official yet I think it's pretty safe to say the US has been in a recession for at least the past quarter.

The question I ask is, does a recession make more or less people attain their CCIE? I could see two possibilities here. First, perhaps the fear of a tightening job market would drive some to get this certification knocked out. On the other hand, having less money to pay for training and lab attempts, along with perhaps a lower possibility of rewards from passing, may cause some to put the CCIE on the back burner.

Between March and September, the rate of attainment of new CCIEs was 9.7 per day. According to InternetworkExpert.com, their latest CCIE number as of November 5th was 22542, vs 21910 on September 3rd. Therefore, over the past two months, this equates to 10.0 CCIE numbers awarded per day.

Now this is hardly a scientific study, since I don't have access to the exact amount of CCIEs given out on a particular day and I'm comparing a 6 month timeframe to a 2 month timeframe.

But it certainly does appear that this global economic slump is having no effect, or even a slightly positive effect, to the attainment of new CCIEs.

BGP Exam 642-661

I'm gonna take a stab at this exam sometime this week, possibly as early as today. From looking at the exam topics I just couldn't imagine having too much difficulty with this. Aside from ORF and Hierarchical Route Reflectors, I have quite a bit of experience on the rest of items.

I hope I can pass this today and get myself back on the right track.

Monday, November 3, 2008

I have been defeated by BGP+MPLS

Today I failed BGP+MPLS for the 3rd time. During the exam I thought I had it this time. Many of the questions were repeats and I felt pretty good about the answers. I did do better this time, but I wasn't quite there.

I'm throwing in the towel on this one. I'm pretty sure what's killing me is that I just don't have the practical experience with BGP.

Jumping in to CCIE studying would certainly give me the hands on. I was hoping to use the CCIP to springboard into that, and to be honest I feel like it has already served that purpose. I understand the concepts of MPLS pretty well, I think it's just some of the peculiarities that are throwing me off.

So what now? I've had it with this exam and I'm giving up on it. I was hoping to be into CCIE SP studying by the end of this month. I really want to recertify my CCIE R&S by the end of the year as well.

That basically leaves me with three options:
  1. Take the BGP and MPLS exams separately. I think that would be helpful because the score reports should be a little more granularized. That way I should at least know what my weaknesses are. The BGP+MPLS score report is pretty vague.
  2. Take the R&S CCIE Written again to renew my cert and then decide what to do next.
  3. Jump straight to the SP CCIE Written. I might end up failing it repeatedly as well.
  4. Jump straight to studying for the CCIE Lab. I should get enough hands on experience with MPLS to come back and knock out the CCIP after a little while with it. Of course once I'm a month or two into labbing it up on the IE, I probably wouldn't want to bother backtracking for the CCIP.
I think I'm going to knock out the BGP exam because I shouldn't have any problems with it. Then, depending on how that goes, I'll regroup from there.

Friday, October 10, 2008

Failed BGP+MPLS Again!

I tried to pass 642-691 again today and once again I didn't make it. My score actually went down. My wife asked me if that means I got stupider--apparently I have!

So what to do now? Do I split them up and take BGP and MPLS exams separately, or keep banging my head against the wall on this exam.

I'm going to digest this for a bit and make up my mind when I'm a little less pissed off at the people who make up these ridiculous questions!

Tuesday, October 7, 2008

Changed MPLS Books Yet Again!

I've now switched over to MPLS Configuration on Cisco IOS Software. This book seems to be the most readable of the bunch and has lots of pretty pictures. I'm going to review the VPN portions here and lab up some of the exercises. I hope to take another stab at the BGP+MPLS exam by Friday.

Thursday, September 18, 2008

Failed 642-691 BGP+MPLS

I attempted the BGP+MPLS exam and didn't quite make it. I was hoping my good knowledge of BGP would be enough to carry my through my limited MPLS knowledge.

The BGP portion went fine. I'd estimate I got over 90% on those questions. Unfortunately many of the MPLS questions were from areas I didn't study enough on. That being said, I had an idea on many of the MPLS questions, I just wasn't quite sure what the correct answer was.

The bottom line is I have to do a lot of studying on MPLS VPNs. I think if I get more comfortable with them I'll be ready to go. I'll try to focus on that topic and take the exam again next week.

Wednesday, September 10, 2008

CCIE Worldwide Statistical Analysis

PBS has an interesting article here regarding the analysis of the number of CCIEs per nation.

The writer makes the bold statement that "Looking 30 years into the future I think it is clear that the regional leaders will be China and Korea, NOT India and Japan."

Wednesday, September 3, 2008

CCIE Numbers

Today marks 6 months since I passed the CCIE lab. My number is 20152. A quick look at internetworkexpert shows the most recent number issued using their materials is #21910.

Knowing this yields the following statistics:
  • There have been 1758 new CCIE numbers awarded in the past 6 months
  • Averaged out, this is 293 per month or approximately 10 per day.

For those of you who want a number in the 20,000s, you have approximately 2 years and 4 months left, assuming the rate stays the same.

Tuesday, September 2, 2008

Isn't it Ironic?

I find it ironic that the word asymmetric is spelled with only a single s but double m's. I keep trying to spell it assymmetric, but I guess it sticks better to the meaning of the word the correct way.

So, not much MPLS studying was completed last week due to an asymmetric routing issue I ran into at work that took a bit of time to figure out. There is a great article here that explains it.

Asymmetric routing happens when a packet leaves a network through one path and comes back in through a different path. Take a look at the following picture, disregarding the Multicast lingo.

Imagine if a packet comes into the switch on the left, leaves the router on the left to the cloud. Then, a return packet enters the router on the right, back to the switch on the right, and finally back to the switch on the left.

Now, when the packet enters the switch on the left originally, the switch updates its cam table with the source mac address. The packet passes up to the router on the left, and out to the cloud.

When the packet returns, it comes through the router on the right, and down to the switch on the right. This is where there is a problem.

Since the outbound packet never went out the switch on the right, the switch never loaded it's mac address. And what does a switch do when it doesn't know the mac address? By default it floods the packet out all interfaces associated with that vlan (extra credit for CCIE students who know how to turn this floding off). This includes access links, trunk links, etherchannels, and whatever else. So if there is a chain of 15 switches, this packet is likely to get flooded across all interfaces of all of those downstream switches.

Now how do we stop this from occurring? We need a little help from ARP. When the host wanted to send an outbound packet, it had to send an ARP request. An arp request is a broadcast IP packet that sends an IP address and awaits the response of the MAC address associated with that IP address.

Since this is a broadcast packet, it is flooded throughout the broadcast domain (i.e. vlan). This causes all of the switches to update their cam tables and stop flooding the packet.

So why does this happen to begin with? One of the main reasons is due to mac aging-time. A router by default generally has a mac aging time of 4 hours. A switch by default generally has an aging time set to 5 minutes. So, when a router learns a MAC addresses, it doesn't need to relearn it for 4 hours. However, when a switch associates a MAC address with a port, it loses this information after 5 minutes. After 5 minutes, the only way a switch that's not in the path can update its cam tables once again, is for another broadcast to occur.

A switch will not send an arp request when it loses an entry from its cam table, however, a router must since it needs the mac address to send traffic to the host. At default mac aging settings of 4 hours for routers and 5 minutes for switches, asymmetric traffic will be flooding for 3 hours and 55 minutes of every 4 hours. This is probably not desired operation. Therefore, when asymmetric routing exists, routers and switches need to have their mac aging times set identically.

Thursday, August 21, 2008

MPLS Study Materials

I've been bouncing around this week evaluating different study materials and I think I've finally settled on a book that works.

MPLS Fundamentals (ISBN 1-58705-197-4) seems to be the most readable of what I've seen. In general, I just find the whole MPLS topic to be extremely dry--I'm not sure why. Possibly since most of my career has been spent as an ISP customer, the inner workings of MPLS was never really relevant to me.

It could be worse, I could be studying storage...

Thursday, August 14, 2008

MPLS Exam Cram

This is the start of notes on my cramming for the MPLS exam. It will consist of new or interesting MPLS information that I need to commit to memory.
  • Multiple labels can be inserted, and the bottom-of-stack bit is set on the last label
  • Labels consist of a 20 bit label, 3 bit experimental field, 1 bit bottom-of-stack indicator, and 8 bit TTL
  • Ethertypes: 0x0800 is IP, 0x8847 is unicast with at least one label, 0x8848 is multicast with at least one label
  • More than one label is used for VPNs and TE
  • An LSR can push, swap, or pop labels
  • MPLS is split into the control plane and data plane
  • FEC: Packets forwarded based upon a common characteristic
  • For Unicast IP Routing, an IP routing protocol and a Label distribution protocol are required
  • Label distribution protocols match labels with networks
  • FEC is the destination network
  • PIM can be used for multicast, and the FEC is the destination multicast address
  • TE requires OSPF or IS-IS with extensions
  • RSVP or CR-LDP establishes tunnels and propagates labels
  • With QoS, the FEC is the destination network and CoS
  • In VPNs, two labels are used: Top points to egress router, second points to the outgoing interface on the egress router, or a routing table
  • FEC is the site descriptor or VPN routing table

Tuesday, August 12, 2008

BSCI Complete

The exam ended up more or less as I was expecting. Some parts were relatively easy, some were a pain, and always an overabundance of annoying questions that seem more to be out to test attention to detail rather than knowledge.

My score was a bit higher than on QoS, and passing, but still low enough where I'm not concerned that I overstudied for the exam.

On to BGP+MPLS, which will complete the CCIP. After that it's finally onto the SP Written, which will renew my CCIE certification.

Even though I'm planning on doing the SP lab after that, it is a little tempting to just knock out all of the professional level exams. I have enough experience in Voice and Security as well where I could probably hit an exam every couple of weeks and have the CCVP and CCSP complete by the end of the year.

The CCIE lab is just such a time and energy suck. But I'm leaning toward going ahead and studying for the lab sonner rather than later. There are three main reasons for this.

First, I'll be freshest on the lab material after just studying for the CCIP and written. If I switch tracks I'll probably have to relearn a few things.

Second, assuming I eventually pass the Service Provider lab, I can then jump right into the CCSP, which would give me a break before working on the Security lab. I'm definitely saving voice for fourth just because it has the reputation for being the toughest. Storage would be last since I have absolutely no experience with it and it will probably take me a lot longer.

Monday, August 11, 2008

BSCI Exam - 642-901

Ok, the very fact that I have to take this exam is a little strange. I have been a CCNP since 2004 and am a CCIE. Why don't these fill the "routing" exam requirements?"

According to the certification progress website, the version of BSCI exam I passed over 4 years ago is too outdated to count. So I have to knock this exam out instead.

As far as I can tell, there is only one topic that isn't covered by the R&S written: IS-IS. I'm guessing they're just going to be asking questions about the intricacies of L1, L2, and L1/L2 behavior.

Aside from that, I'll need to brush up on all the "booksmart" material such as timers and metric computation.

I think I'm going to shoot to have this knocked out by Friday.

I have my weekends back

On Friday I completed my final presentation for my Master's Project at Towson University in Maryland. For the first time in over 5 years I don't have any studying or homework to worry about over the weekend. All the more time to spend studying for CCIE #2? Nah, I think I'm going to be taking a few weekends for myself until I knock out the written and am ready to start working on the lab.

Wednesday, August 6, 2008

CCIE Worldwide Statistics

It's official, North America no longer holds most CCIEs. As of the recently released statistics here, Asia now has more.

Monday, August 4, 2008

QoS Exam Passed

Wow, all I can say is do not underestimate this exam. I knew it wasn't going to be simple, but it was much more challenging than I expected. If I missed one more question I would have failed. Actually, before I saw the congratulations message, I thought I was going to be rescheduling this thing.

I'm off to do my Master's presentation on Friday, so I won't be starting to study for another exam until next week sometime.

Thursday, July 31, 2008

QoS exam 642-642

I'm feeling pretty good about this exam and will take it either next week or the following week. It's amazing how much LESS material there is in a professional level exam vs an expert level one.

As there's a lot of overlap with my R&S CCIE and my previous voice experience, I'm not stressing out much over this. Of course, there's always the fear of taking it for granted and failing and wondering how the heck I can pass the CCIE written and Lab and bomb the QoS exam.

Anyway--here are the topics I need to commit to memory:
  • Higher drop precedence means more likely to be dropped. But higher IP precedence means less likely do be dropped. Huh? Who designs this stuff anyway? Just remember, AF11 will be dropped before AF21; however AF12 will be dropped before AF11. That last number means drop precedence, as in higher priority to be dropped. Whereas the first number means the traffic itself is higher priority, and less likely to be dropped. It makes me think they designed it this way simply because they knew they'd get a few good test questions out of it.
  • RTP Header Compression also compresses the UDP and IP headers, and therefore must be enabled on both sides of a link. Could the name be any more misleading?
  • COPS, aside from one of my wife's favorite TV shows, is a protocol that allows centralized monitoring and control of RSVP. Bad packets, bad packets, what'cha gonna do? What'cha gonna do when QoS comes for you?
  • ECN is like frame-relay adaptive shaping, except it's not shaping and there's no frame-relay. If a router is nearing congestion, it can use the last two bits of the ToS field to notify the upstream host. Then the upstream host relays this information to the sender. Finally, the sender slows down sending. It's like FECN and BECN, and like being issued a warning before WRED steps in and destroys your packet.
  • BGP can use communities to propagate QoS policy information (bgp-policy command)

Monday, July 28, 2008

CCIE Service Provider Next

It's official, I'm definitely going for Service Provider next.

I'm considered studying for the lab first and then knocking out the written once I'm comfortable with the hands on, but I'm changing my approach.

I'm going to go ahead and knock out the CCIP first. This should put me well on the way toward passing the written. It's also a little more manageable to cover the material this way.

The first exam I'm going for is QoS, since there's a lot of overlap with R&S and I've had a decent amount of experience with it. I picked up the Boson ExSim test for the exam. I've always been pretty fond of Boson and have been using them for over 6 years. They have a heck of a lot of material, are inexpensive, have great explanations, and the questions cover the topics well without being too close to the real exam.

My strategy is as follows:
  1. Take a 20 question Boson practice test every day
  2. Review the DocCD on anything I miss
  3. Review Safari Books Online if I need further explanation of the topic
Since there are roughly 250 questions, I should be ready to knock out each professional level exam in about 2 weeks with this approach.

Friday, July 25, 2008

Goodbye, Randy Pausch

I first learned about Randy's story last fall from one of my professors. The night after I heard, I watched The Last Lecture on Youtube. I've seen quite a few inspirational speakers over the years, and most have a knack for making me feel all pumped up for a few days. But after a week or two I can barely remember any of their lessons.

This is not true with Randy Pausch. I can honestly say his lecture changed my life. I'm going to paraphrase a bit, but two points in particular had a big impact on me:
  • Brick walls aren't there to stop you, they're there to prove how bad you want something
  • You have four categories of tasks: urgent and important, non-urgent and important, urgent and unimportant, and non-urgent and unimportant. Do the non-urgent important tasks before the urgent unimportant ones.
These are two VERY important pieces toward the CCIE. The lab exam is a BIG brick wall. It will make you prove how bad you want it. It is also generally going to be non-urgent and important. If you really want it, study for it before the things that "need" to be done right away but don't really matter.

Thank you Randy, you will be missed.

Thursday, July 10, 2008

What to do next redux

If you've noticed, I have bounced around the last few months regarding what I want to expend my efforts on next. I know I need to do something, I'm just not sure what. Since whatever it is will turn out to be a major undertaking, I don't mind if it takes a long time to make up my mind. In no particular order, some of the items on the list are:
  • Get all of the CCIEs (probably Service Provider next)
  • Get a PhD in Computer Science (finishing MS this summer)
  • Author/co-Author a book
Those are the main three, of which I'd like to complete one in the next five years. I'm leaning toward the CCIE route since I think it's most in line with my career aspirations. I'm not planning on being a researcher or professor, so all the PhD would really get me is another suffix to my name.

I was previously thinking of going for a CCIE in Security next, but that was mostly because I didn't see myself doing much with SP networks. As it turned out, that has changed so it makes more sense now.

Wednesday, July 9, 2008

Stumble!

I dropped in a new Firefox plugin called Stumble! the other day that really caught my attention.

If you've ever had a Tivo, it's a similar concept to that, but for websites. When you're on a webpage, you give it a thumbs up or thumbs down.

From there, it ranks pages (which you can view on Google in an Amazon style star raking system), or you can have it give you random pages based on your preferences.

You can even view the pages I gave thumbs up to here.

Thursday, July 3, 2008

Goodbye Microsoft

A few months ago the upgrade path for my MCSE in NT and 2000 expired and I'll have to take a bunch of tests if I ever want to upgrade it. However, since it's been about 4 years since a company has given me domain admin rights, I'm not very concerned.

Last year I installed Vista on my home PC because I got the business version for free--or I should say included with the $20,000+ I paid Towson University over the past 3 years in the quest for a Master's degree.

I'm not a Vista hater. It was ok, but more than anything it's just plain slow. With 1GB of ram and a 3GB single core processor it was having a rough time. Like my MCSE, my computer's upgrade path had expired (DDR1 RAM, Socket 478, no PCI Express).

So I could have went back to XP, which has reached end-of-sale status, or give something else a try. I chose the later and went with Ubuntu.

I've always had a linux box on the side, but never ran one full time. Now I'm running two. There are some things I like, and some things I'm not so fond of. But without a doubt the single biggest thing I love is the sheer speed. The install took 20 minutes. My computer takes about 20 seconds to boot up or shut down. Gone are the days of starting it up and getting a cup of coffee. No more hard drive thrashing or blue screens of death.

So far there are only four needed programs I haven't been able to get to work natively. Wine solved two of these by simulating a Windows environment for the program. Unfortunately two other programs (I'm not naming them because they may work and I just haven't quite figured them out yet) don't work and I am stuck with vmware for these two programs for the time being.

I'm liking Ubuntu more and more every day. If you've thought about giving it a try, here are some reasons.

Wednesday, July 2, 2008

The Importance of HSRP groups

When using the standby command to setup HSRP, one optional parameter is to use a group number. When I configure it, I typically always use one, even though I never really had a good reason to do it.

One thing to keep in mind is dealing with the virtual MAC address HSRP uses. By default, this MAC address is 0000.0c07.ac00, if no group number is specified. If a group number is used, it is added to the last word. For example, group three becomes 0000.0c07.ac03. Further details here.

In general, you will usually only use one HSRP group per vlan, so this isn't a problem. But if you have another device spanning multiple vlans that needs to talk to multiple HSRP speakers simultaneously, this can create MAC address conflicts if the same HSRP groups are used.

Saturday, June 21, 2008

Back From Silence

I haven't posted much as of late. It's not because I didn't have a lot to say, that's for sure. A couple of months ago I got the itch for a career change. Fortunately, having a CCIE makes this relatively easy to do--recession or no recession.

If any of you out there are concerned about the occasional stories about how the CCIE is becoming worthless, let me assure you it is definitely not. Posting my resume on Monster yielded a barrage of opportunities.

After everything was said and done, I'm now working for Cisco Systems in RTP. Everything is going great and it's truly an excellent company to work for. Now I have the unusual experience of going from being one of the most knowledgable in my company to realizing I have a long way to go.

Long story short, my previous story of becoming board will not be coming to fruition any time soon.

Monday, April 7, 2008

What to do next?

Bottom line, I'm torn. I know I have a lot to learn in a number of areas, but I'm not sure where to go next.

Do I go for a CCSP or CCVP? Or straight to the CCIE written in voice or security?
I'm a little reluctant to work on a second CCIE because I'd like to reap some of the benefits of the first one before working on the next.

My weaknesses in Security have shown over the past few weeks when I've missed little things here and there.

And then there's other non-Cisco options such as CISSP or Ethical Hacker. This summer I'm finishing a Master's in Computer Science, so I just don't think those two certs would matter much with a Master's and a CCIE.

Then there's always the thought of going for an MBA or a PhD in Computer Science. Neither seem too appealing to me at this time.

Friday, April 4, 2008

April Fools RFC

I look forward to these every year.

RFC 5241 - Naming Rights in IETF Protocols
RFC 5242 - A Generalized Unified Character Code: Western European and CJK Sections

I've also added a couple of my all-time favories to the list of links to the right.

Wednesday, March 19, 2008

More Issues

Naturally, the turning off of DNS doctoring has created more issues. This was, to a certain extent, to be expected. But with our public website being down, it was the surefire way to fix it, so we went with that solution.

The issue now lies on the inside network. Anyone who accesses a site via its public FQDN now must use the outside public IP rather than the inside private IP. As long as sites resided in the DMZ, this was taken care of by reconfiguring the static translation to use the outside public instead of the inside private.

There are two issues where this could not be resolved, however. First, if the server resides on the private network, instead of the DMZ. Unfortunately I inherited a bunch of these. I'm trying to get them removed, but still have a ways to go. Fortunately, I haven't found one that was a show stopper yet. If I do, I'll probably have to NAT it on our inside core switch. But I'd like to avoid that if possible.

The second issue is for people who accesses our DMZ services from remote sites across the VPN. Since they now reference a public instead of private address, they traverse the public Internet. This has created issues for people trying to do things like edit the public website remotely. Naturally the firewall doesn't allow this from the public internet.

We've been able to survive the little issues thus far. We also discovered the reason for the problem. Sever static NAT translations that I inherited were applied backwards. This was causing DNS doctoring to occur to the public internet! I'm not sure why this wasn't broken before.

So we know the fix, now I just have to convince my VP that we won't break the public website again. It's looking like it will be at least 2 weeks before we can put the change through. I just hope we don't put in too many band-aids between now and then that we can't go back to the correct way.

Sunday, March 16, 2008

More Issues

Some previous firewall configuration was carried over as part of the migration as well. Unfortunately, this created some more problems. For some reason, DNS doctoring was turned on pretty much everywhere. It was being overused to the point that DNS replies of internet addresses were getting overwritten with DMZ addresses. Naturally, this caused a number of internet services to fail.

Now I really haven't messed wtih DNS doctoring much since the alias days. It seems to be a lot easier now, since all one needs to do is to add the dns option to the static translation.

But the real question is, why wasn't this failing before the upgrade. I don't know. I turned off DNS inspection to kill this. That fixed the issue, but it took time to propogate.

The Default DNS TTL is 3 hours, so anyone who grabbed a bad record would have to wait up to 3 hours for their upstream DNS servers to get corrected.

To check the TTL remaining, nslookup can be used

c:\>nslookup
Default Server: cns.manassaspr.va.dc02.comcast.net
Address: 68.87.73.242
> set debug
> www.somecompany.com
Server: cns.manassaspr.va.dc02.comcast.net
Address: 68.87.73.242
------------------------
Got answer: HEADER: opcode = QUERY, id = 5, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS: www.somecompany.com, type = A, class = IN
ANSWERS: -> www.somecomapny.com internet address = 10.1.1.100
ttl = 205 (3 mins 25 secs)
------------
Non-authoritative answer:
Name: www.somecompany.com
Address: 10.1.1.100
>

Late Night Troubleshooting

Unfortunately, issues continued late into the night. The joy of working on intermittent issues. On several occasions we thought we had it resolved, only to have the problems return later.

As it turns out, a transparent firewall that permits everything still runs packet inspection. We placed one in between two mail servers. It was inadvertently inspecting SMTP and occasionally killing communication between the servers. This only seemed to happen with a high message load.

Over the years, Cisco has been driving me and many others crazy with smtp. This was actually the first place I looked on our external firewall, and it was not present. I never even thought to look at the transparent firewall until later.

A primer on mailguard, etc.
Since PixOS 4ish, Cisco dabbled in application inspection with the mailguard feature. Since SMTP only has a handful of commands (HELO or EHLO, DATA, etc.) mailguard attempted to only allow these commands and to play with some banners and things as well to help protect the mail server.
In Pix 6ish this was now called fixup smtp 25
And now in Pix 7 it's called inspect esmtp

And over all of these years, the general rule is always to disable it immediately.

There are certain things that Cisco does that amazes me. Why, when after 10 years of configurations being changed out of the box, does Cisco not just make them default? Off the top of my head, some examples are
  • Turn off SMTP proxying/fixup/inspect/mailguard
  • Disable auto-summarization
  • Turn on service password-encryption
  • Turn on service timestamps
  • Automatic "terminal monitor"
I'm sure Cisco would say it's because of compatibility issues with those upgrading from older code. But come on, somebody upgrading to 12.4 should at least have some inkling about auto-summarization.

Saturday, March 15, 2008

Data Center Rebuild

Today we redesigned the core of our datacenter. Some of the configuration tasks included:
  • HSRP with object tracking
  • dot1q trunking to a router
  • transparent firewall BPDU passthrough
  • BGP advertise-map configuration
One of the primary benefits of this configuration was it allowed us to add some functionality to the network, while replacing a number of layer 3 switches with layer 2 ones. This allows us to use less expensive resources and redeploy the freed up devices to more suitable locations. It also simplifies the network, which is generally a good thing.

Just from my experience with the CCIE lab, I changed my normal plan of attack here. In the past I was more one who prefered to gut everything and replace it all at once. Now, I tend to follow lab strategy and do one piece at a time, verifying as I go.

As with the lab experience, things go much slower this way, but it gets done right. When something doesn't come up I know exactly where to look for the issue instead of having to troubleshoot everything.

As expected, there were a few bugs to work out, but just about everything ended up as designed. The great work up front and during the implementation by the whole team really paid off.

Some of the learning experiences were
  • A firewall in transparent mode can pass layer 2 information, but not CDP. A ethertype access list is required to allow BPDUs to pass. This was necessary so that a backup link can be used while letting rstp block the link. If this didn't work, another option would have been the "switchport backup" option for the 2560/3560 series switches, which functions a bit like a layer 2 version of the backup interface router configuration command.
  • It always helps when default gateways are set correctly
  • When using Hyperterminal to paste commands, make sure to set the character delay to prevent buffer overflows
  • Duplicate IP addresses are very bad things
Most of these were minor and corrected quickly.

Saturday, March 8, 2008

How the CCIE helped in the first week

On Friday night I had a BGP implementation to do at our India location. There have been a few transatlantic cable breaks of late so we really needed to get a redundant provider up and running. The change began at 10pm with a relatively simple setup. All I want is a default route and I'll use as-path prepending and weight to ensure the primary circuit is preferred.

While one ISP got it correct, the second did not. My router wasn't maxed out on memory, so I needed to ensure I didn't have the entire BGP table. Sure enough, once the BGP adjacency came up, I began to receive more than I bargained for.

Now the race was on. I had to filter everything but the default route before the router ran out of memory. Of course, just about any CCIE should be able to do this.

ip prefix-list DEFAULT permit 0.0.0.0/0
!
route-map NODEFAULT deny
match ip address prefix-list DEFAULT
route-map NODEFAULT permit 20
!
router bgp xxxxx
neigh xxxx route-map NODEFAULT in

It took about 30 seconds. No DocCD needed. I didn't even have to use the ?. It worked right the first time.

This is why the stress and pressure and time constraints exist in the lab. Unexpected things happen. Sometimes you have to act quickly. Consequences can be severe.

A new purpose

It has been almost a week since I passed the CCIE lab exam. There were a number of congratulations and a celebratory dinner alone with my wife. Aside from that it has been life as usual. No ticker tape parades. No job offers for obscene amounts of money.

My life has changed already though. It's Saturday and I did not wake up at 6am. I slept in until nearly 11. My wife and son are out of town this weekend, so I have been watching movies and hanging out with my dog. At some point I need to lower my son's crib since he's very close to pulling himself up.

The next change is that I'm finding it difficult not to brag. I called a few friends and sent a few more emails. But most people would probably not know unless they paid attention to my new email signature. I'm not sure if I'll keep it in there long-term, but I will for at least a week or two.

I'm also not sure what to do next. I'm planning on casually studying for the security track. I'm really not in a rush. It took me 10 years to get the first CCIE, so that should be too difficult to improve upon.

One thing I did notice. There are a lot of blogs of people either talking about studying for the CCIE or helping others to get there. But what are you supposed to do after you're certified?

There is no official blueprint for what to do after you're certified.

So, the new purpose of this blog is to discuss what happens next.

Sunday, March 2, 2008

Passed!


Now I need to figure out what to do with all my newfound free time.


Ed Balow
CCIE #20152

Saturday, March 1, 2008

CCIE Attempt #2 Task 1/2

Here I am at the hotel in RTP the night before my second attempt. I arrived early enough to have a nice dinner and talk football with the bar patrons for a bit. To my dismay, the Bears traded Berrian to the Vikings. So now they are down two starting wide receivers, and are about to lose Lance Briggs, with only a 1-year extension for Rex that's-just-Gross-Man to show for it. Not looking to be too promising of a season.

The first task of the lab, that many seem to fail, is getting a good night's sleep the night before. I bombed that miserably at my first attempt. I came down to RTP with my family and my dog. My 7 month old son was still collicky at the time and thought he'd help me study until 4am. Unfortunately I don't understand babytalk so all it meant was that I only got about 2 hours of sleep. I ended up getting to the lab about 15 minutes late. By 6 hours in I was feeling pretty drained and didn't have much motivation to do a detailed 2nd verification of everything.

Due to some misconceptions I had that I realized in later studies, I probably would not have passed anyway. But I'm going to do everything I can to get some solid sleep tonight. I did a test drive to the Cisco campus to make sure I know the way. I have a 6am wakeup call scheduled, my cell phone alarm, and hotel room alarm set for that time as well. So I'm calling my sleep preparations task 1/2. Let's just hope I can follow through.

If you happen to read this, Laura, thanks for all of your support this year. You've allowed me to get a heck of a lot of studying done on the weekends and I really appreciate it.

Friday, February 29, 2008

Contingency Plan

I really hope I don't fail. I feel as if I've learned pretty much everything I'm going to learn from the IPExpert an Internetwork Expert labs. I'll be a little unsure as to where to turn next. With the typical CCIE difficulty metric being a 7/10, I feel my knowledge is about 8.5/10 at this point.

I've told my wife I'm only taking 5 attempts. If I don't get it by then I'll give up. That gives me 4 attempts left.

I do get a little frustrated with IPExpert and IE labs. There are a number of mistakes that are obviously from failure to properly upgrade their workbooks over the years. I personally find this to be detremintal to my studying. I've had to get use to assuming things might need to be a little different than they way they are worded. On the actual lab, this is BAD. I need to make sure to assume absolutely nothing.

I don't feel there's anything else to learn with a free retake of the IPexpert bootcamp. Perhaps taking it with Scott for a different perspective would help.

There has been a lot of "testimonials" on the Narbik bootcamp lately. It's to the point that I'm actually steering away from it. From the reviews I'm reading, it's sounding more like he's teaching "stupid router tricks" than anything else. My impression could be wrong, so I'd open up some discussions on Monday if I need to.

I really feel the best preparation for me at this point is the Mock Labs. I've taken all but 2 of the IE mock labs. Another option would be to take the IE Mock Lab bootcamp.

Another possibility would be to swtich to NetMasterClass. A lot of people seem to recommend using them in tandem with IE. Their CheckIt labs are pretty expensive though--$250 each or 3 for $635. They also have a DoIT volume 2 plus 5 CheckIt labs package for $1324, which is about the same cost as a lab attempt.

Since I have been successful at studying at home, I think this would be a good approach to take. It would give me 1 graded lab a weekend and 1 workbook lab a weekend with 5 weekends before another attempt.

So that's my plan of attack. Purchase the $1324 package from NMC and reschedule for a month out.

Knowledge Assessment

So here I am, 2 days out from my second attempt. All in all, I'd say I'm feeling pretty good, but I certainly wouldn't say I'm overconfident. I didn't feel the lab itself was too hard last time. I finished the first run at about 6 hours and was only confused by a couple of tasks. Through further studying, I've realized I did a couple of other tasks wrong and probably should have asked a few other questions.

Here is a list of things that I still feel I could use some work on:
-Catalyst QoS mutation maps
-OSPF NSSA Type 7 suppression
-Reachability Verification--I always seem to miss a BGP route somewhere
-MBGP
-Multicast Troubleshooting--I'm still slower than I'd like to be
-PIM Mapping Agent placement
-CBAC and Reflexive ACLs--I'm still gunshy to implement these
-NTP--remembering to apply the trusted key to the ntp server
-Extended login options

Wednesday, February 27, 2008

Since my failed attempt

Here is what I've completed since my failed attempt

IPexpert labs: 1
IE labs: 5
IE Mock Labs: 2
Cisco CCIE assessor labs: 1

That's 72 hours of rack time in the past month.

Sunday, February 24, 2008

IE Lab 17 breakdown

Not much to complain about. I knew I missed a couple of the oddball system management and security pieces. I spent a heck of a lot of time verifying bgp and igp. I found a few additional issues in doing that. Even with all that time I still finished with an hour to spare.

IE Lab 17

This is quite possibly my last practice lab before the real thing on Sunday. In light of my weaknesses, my plan is for the following:

Take extra time verifying every single last thing
Don't worry too much about time
Take extra time playing around with multicast
Do each QoS question using MQC and Legacy formats
Play with NAT

7:15 start
7:41 diagram complete
7:54 readthrough complete
8:18am 1.1 complete, 3 points
8:18am 1.2 complte, 3 points
8:19am 1.3 complete, 2 points
8:23am 1.4 complte, 2 points
8:27am 1.5 complete, 3 points
8:31am 1.6 complte, 3 points

Switching complete, 16/16

8:48am 2.1 complete, 3 points
8:48am 2.2 complete, 3 points
8:48am 2.3 complete, 2 points

Frame complete, 8/8, 24/24

8:54 3.1 complete 3 points
8:59 3.2 complete, 3 points

PPP complete, 6/6, 30/30

9:08 4.1 complete, 3 points
9:17 4.2 complete, 3 points
9:23 4.3 complete, 2 points
9:28 4.4 complete, 3 points
9:41 4.5 complete, 2 points
9:45 4.6 complete, 2 points
9:49 4.7 complete, 2 points
9:57 4.8 complete, 2 points
10:06 skipping 4.9, 0/3 points

IGP compelte, 19/22, 49/52 total

10:24 complted 4.9

IGP complete, 22/22, 52/52 total

10:29 pingtests complete

10:56 5.1 complete, 3 points
11:13 5.2 complete, 3 points
11:41 5.3 complte, 3 points

BGP complete, 9/9, 61/61 total

12:26 pingtests complete

12:39 6.1 complete, 3/3
12:55 6.2 complete, 2/2
12:55 6.3 complete, 3/3

Multicast complete, 8/8, 69/69 total

1:00 7.1 complete, 3 points
1:08 7.2 complete, 3 points

IPv6 complete, 6/6, 75/75 total

1:10 8.1 complete, 2 points
1:14 8.2 complete, 3 points

QoS complete, 5/5, 80/80 total

1:27 9.1 complete, 2 points
1:32 9.2 complete, 2 points
skipping 9.3

Security complete, 4/6, 84/86 total

1:38 10.1 complete, 3 points
1:38 10.2 complete, 2 points
skipping 10.3

System management complete, 5/8, 89/94 total

1:59 11.1 complete, 3 points
2:05 11.2 complete, 3 points

IP Services complete, 6/6, 95/100 total

Lab complete, 95%, under 7 hours

Saturday, February 23, 2008

CCIE Assessor Results

I cannot get into many details here due to restrictions.

I did not pass. I broke this down into three reasons:
40% stupid mistakes
40% not enough time
20% not enough knowledge

Stupid mistakes hurt me on switching and redistribution. The main fault here was lack of verification.

Lack of time hurt me on Multicast and IP Services. I mostly blame this on not looking things up on the DocCd. If I had more time I would have looked them up and more than likely got correct.

Lack of knowledge hurt me on Multicast and QoS. There were items here I more than likely wouldn't have got correct, even if I had enough time.

So what does this mean? If I make no stupid mistakes, verify everything, and use the DocCd exhaustively for anything questionable, I can barely pass.

I have 8 days left until my next attempt. I need to get better with Multicast, QoS, and IP Services quickly. As far as stupid mistakes--VERIFY EVERYTHING!!!

CCIE Assessor

6:45am Lab Started
7:03am Diagrams complete
7:14am Readthrough complete
7:22am 1.1 complete, 2 points
7:30am 1.2 complete, 2 points
7:38am 1.3 complete, 2 points
7:41am 1.4 complete, 2 points
7:44am 1.5 complete, 2 points

Section 1 complte, 10 points

7:49am 2.1 complete, 3 points
8:09am 2.2 complete, 2 points (unable to verify)
8:19am 2.3 complte, 3 points
8:25am 2.4 complte, 3 points
8:30am 2.5 complte, 2 points
8:32am 2.6 compelte, 3 points
8:35am 2.7 complte, 3 points

IGP complete, 19/19, 29/29 total

Pingtests complete, 8:47am

8:53am 3.1 complete, 2 points
9:14am 3.2 complete, 2 points
9:17am 3.3 complte, 2 points
9:23am 3.4 complete, 2 points
9:25am 3.5 complte, 2 points

BGP complete, 10/10, 39/39 total

skipping 4.1
9:27am 4.2 complete, 1 point
9:37am 4.3 complete, 1 point

Sunday, February 17, 2008

IE Lab 16

I realized I've already done Lab 12, so I'm going to Lab 16.

8:15am Lab started
8:36am diagrams complete
9:15am readthrough complete
9:32am 1.1 complete, 3 points
9:47am 1.2 complete, 3 points
9:55am 1.3 complete, 3 points
10:02am 1.4 complete, 3 points

Switching complete, 12/12

10:12am 2.1 complete, 3 points
10:49am 2.2 complete, 3 points--bridge 1 route ip
10:53am 2.3 complete, 3 points
10:55am 2.4 complete, 2 points

WAN complete, 11/11, 23/23 total

11:06am 3.1 complete, 3 points
11:43am 3.2 complte, 3 points
12:09am 3.3 complete, 3 points
12:17am 3.4 complete, 3 points
12:19pm 3.5 complete, 3 points

IGP complete, 15/15, 38/38 total

12:19pm taking lunch
1:02pm back from lunch
1:50pm Task 4.1 complete. There was missing information on the lab, 3 points
2:02 Task 4.2 complete, 3 points
2:05 Task 4.3 complte, 3 points
2:20 Task 4.4 complte, 3 points
2:24 Task 4.5 complete, 3 points

BGP complete, 15/15, 53/53 total

2:32 Task 5.1 complete, 2 points
3:24 Task 5.2 complete, 3 points
3:31 Task 5.3 complete, 3 points

Multicast complete, 8/8, 61/61 total

3:37 Task 6.1 complete, 2 points
3:41 Task 6.2 complete, 3 points
4:04 Task 6.3 complete, 3 points
4:35 Task 6.4 complete, 3 points

IPv6 complete, 11/11, 72/72 total

4:42 Task 7.1 compelte, 3 points
4:58 TASK7.2 complete, 3 points
5:03 Task7.3 complte, 3 points

QoS complte, 9/9, 81/81 total

5:05 Task8.1 complete, 2 points
5:08 Task8.2 complete, 3 points

Security complete, 5/5, 86/86 total

5:18 Task 9.1 complete, 3 points

Saturday, February 16, 2008

Status Update

Here are some thoughts on the status for my preparations for mock lab #2.

I now understand:
  • How to set cost and port priority for mstp
  • BGP address families
  • ip forward-protocol
  • ospf demand routing
  • ospf authentication null
  • bgp next-hop-self
  • bgp cluster-id
  • police cir

I've changed my strategy as follows:

  • I now make a detailed L2 diagram
  • I now make a loopback checklist
  • I now add multicast information to the L3 diagram
  • I now use 10 telnet windows instead of a single console

I'm still weak with:

  • attention to detail
  • verification plan
  • multicast troubleshooting
  • Catalyst QoS

IE Mock Lab #2 (Repeat)

I scored a 54 the first time around. I better be pretty close to perfect this time.

5:24am lab started
5:42am diagrams complete
6:08am readthrough complete
6:23am troubleshooting complete, 2 points
6:42am 1.1 complete, 3 points
6:42am 1.2 complete, 3 points
6:50am 1.3 complete, 2 points
6:52am 1.4 complete, 2 points

Switching complete, 12/12

7:05am 2.1 complete, 3 points
7:16am 2.2 complete, 2 points
7:24am 2.3 complete, 2 points

Frame relay complete, 7/7, 19/19

7:27am 3.1 complete, 3 points
7:39am 3.2 complete, 2 points
7:39am 3.3 complete, 4 points
8:00am 3.4 complete, 3 points
8:00am 3.5 complete, 3 points
8:15am 3.6 complete, 3 points
8:15am 3.7 complete, 3 points
8:18am 3.8 complete, 3 points
8:36am 3.9 complete, 3 points
8:53am Pingtests complete
9:11am 3.10 complete, 3 points

IGP complete, 30/30, 49/49

9:26am 4.1 complete, 4 points
9:38am 4.2 complete, 3 points
9:43am 4.3 complete, 3 points
10:17am 4.4 complete, 3 points
10:22am Pingtests complete

EGP complete, 13/13, 62/62 total

11:21am 5.1 complete, 3 points
11:25am 5.2 complete, 2 points
11:31am 5.3 complete, 2 points

Multicast complete, 7/7, 69/69 total

11:33 6.1 complete, 2 points
11:46 6.2 complete, 3 points
11:49 6.3 complete, 2 points

IPv6 complete, 7/7, 76/76 total

12:12 7.1 complete, 2 points
12:20 7.2 complete, 3 points
12:29 7.3 complete, 2 points
12:35 7.4 complete, 2 points
12:51 7.5 complete, 2 points (iffy)

QoS complete, 11/11, 87/87 total

12:54 8.1 complete, 2 points
1:00 8.2 complete, 3 points

Security complete, 5/5, 92/92 total

1:07 9.1 complete, 3 points
1:09 9.2 complete, 3 points

System management complete, 6/6, 98/98 total

1:10 10.1 complete, 2 points, 100/100 total

I have 14 minutes left to review

1:28 lab complete. In review I found I missed the CDP domain name.

IE Lab 12

I only had time to complete about half this lab. I made the following mistakes:
  • port security recovery cause is psecure-violation
  • cannot use MAC access-list to filter IP. Use static mac entry instead
  • ip ospf demand circuit
  • I actually got the multicast helper-map figured out, but was testing it wrong. Need to use ip sla to test specific multicast ports

Thursday, February 14, 2008

Mock Lab 5 Score

I scored a 71 on IE Mock Lab #5. Still not passing, but this was ranked a 9/10 so I'm pretty happy with the performance. I'm also getting closer to my score estimates--only 13 points off this time. Here's what I missed that I didn't expect:

Configured an IP on an interface instead of on a vlan, as specified on the diagram. I changed two of these from the initial config, but I must have missed one. -2
Loopbacks were not summarized. I'm suprised here, I spent quite a bit of time on them. It's possible some of my later EGP redistribution broke this again. -2
Missed an OSPF adjacency password. -2
Incorrect IGP metric. -2
Multicast, -4 because of incorrect L2 vlan.
I seem to have lost a point in the wash somewhere.

Lessons learned
  • Compare the diagram to the configuration for review. Device by device.
  • Re-verify summarizations and metrics after EGP is complete
  • Check each ip ospf interface for authentication

These mistakes were nothing to do with the complexity of the lab. I think I just get overwhelmed with review near the end of the lab and don't check every little detail. This happened to me on the actual lab as well. I need to get more disciplined with this.

With the difficulty of this lab, I really feel I have a pretty strong grasp of the technologies and concepts. I just have to do better at verification. Because of this I'm going to adjust my study schedule to the following:

2/16: IE Mock Lab #1. Pretty easy and I better get near 100% on it. Only 41% last time due to little mistakes.

2/17: IE lab #12. Just taking this for the sake of practicing with something new.

2/23: Cisco CCIE Assessor. By now I better be doing a good job of verification. I want to make sure I'm doing tasks to Cisco's level of expectation.

2/24: IE Lab #16. Again, doing something new.

3/1: Rest

3/2: Lab Attempt #2

Sunday, February 10, 2008

IE Lab 10

6:50am lab started
7:21am diagrams complete
7:43am readthrough complete

7:53 1.1 complete, 4 points
8:03 1.2 complete, 3 points

Switching complete 7/7 points

8:07 2.1 complete, 2 points
8:13 2.2 complete, 2 points
8:14 2.3 complete, 2 points

Frame relay complete, 6/6 13/13 total

8:24 3.1 complete, 2 points
8:54 3.2 complete, note traffic share count in sh ip route , 3 points
9:00 3.3 complete, 2 points
9:03 3.4 complete, 3 points
9:22 3.5 complete, 3 points--virtual links can extend for area 0 preference as well
9:26 3.6 complete, 3 points
9:28 3.7 complete, 2 points
10:10 3.8 complete, 3 points--weird stuff. a /24 was getting redis as well. I still don't understand why but it's blocked now
10:14 3.9 complete, 3 points
10:22 3.10 complete, 3 points

IGP complete, 27/27, 40/40 total

10:30 pingtests complete, no issues. Taking lunch
10:45 back from lunch
10:58 4.1 complete, 3 points
11:08 4.2 comlete, 3 points. Had to go back and filter out a default route from ospf->eigrp
11:19 4.3 complete, 3 points.
skipping 4.4. I know how to do this, but it would kill BGP reachability.
12:01 4.5 complete, 3 points
12:31 pingtests complete. Had some sloppy routing decisions to fix up

EGP complete, 12/15, 52/55 total

12.40 5.1 complete, 2 points
12:50 5.2 complete, 3 points
12:50 5.3 complete, 3 points
12:56 5.4 complete, 3 points

Multicast complete, 11/11, 63/66 total

1:00 6.1 complete, 2 points
1:12 6.2 complete, 2 points
1:18 6.3 complete, 3 points

Ipv6 complete, 7/7, 70/73 total

1:38 7.1 complete, 4 points. OSPF doesn't care much for frame-relay fragmentation
1:51 7.2 complete, 3 points. available bandwidth feeds off mincir
2:53 8.1 complete, 3 points. Couldn't verify for some reason
skipped 8.2, 0/3 points. not sure how to change telnet port
3:07 9.1 complete, 3 points
3:07 9.2 complete, 2 points
3:15 10.1 complete, 3 points
3:22 10.2 complete, 3 points
3:27 103 skipped, 0/3 points. Not sure how to renew dhcp every 3 hours outside of interface

Lab 10 complete. 91 points possible. Time to check.

1.1 because I can't read. sw2 transparent -4
4.4 looks like killing reachabilit was fine -3
8.2 rotary -3
9.1 banner exec -3
10.3 funny, I was thinking kron -3

Total score: 84

Saturday, February 9, 2008

IE Mock Lab #4

I didn't do much studying at all during the week. Grad school is picking up now so there probably won't be much time. This is why I moved the real lab for the end of January, originally. I was hoping to get it completed before school started.

Today I'm taking IE Mock lab #4. It has a difficulty of 9, which means it's supposed to be harder than the actualy lab. To make things worse, they put a timer on now and will automatically kick me off the equipment 8:30 after I start.

I'm going to try one different approach this time. I'm going to open 10 terminal windows instead of just the 1. I was afraid before that I would get confused, but I'm sure there'd be a big benefit to catching debug ip routing messages and others if I go this way. I hope by practicing a month with this I'll get the issues straight.

6:32am Started Lab
7:00am Diagrams complete
7:18am Readthrough complete
7:42am 1.1 complete, 2 points
7:42am 1.2 complete, 3 points
8:10am 1.3 complete, 2 ponts
8:10am 1.4 complete, 3 points
8:10am 1.5 complete, 3 points

Bridging and Switching complete, 13 points

8:25am 2.1 complete, 3 points
8:35am 2.2 complete, 2 points
8:35am 2.3 complete, 2 points
8:35am 2.4 complete, 2 points
8:38am 2.5 complete, 2 points

Frame-Relay complete, 11 points

8:45am 3.1 complete, 3 points

HDLC/PPP complete, 3 points

8:52am 4.1 complete, 2 points
8:56am 4.2 complete, 2 points
9:01am 4.3 complete, 2 points
9:22am 4.4 complete, 4 points
10:07am 4.5 skipped, 0 of 2 points
10:20am 4.6 complete, 2 points
10:28am 4.7 complete, 2 points
10:32am 4.8 skipped, 2 points
10:36am 4.9 complete, 2 points
10:39am 4.10 complete, 2 points
10:42 4.11 complete, 3 points
10:47 4.12 complete, 2 points
10:50 4.13 complete, 2 points

IGP complete, 27 of 29 points

11:16 pingtests complete, beginning lunch
11:35 back from lunch
11:45am 5.1 complete, 3 points
12:04pm 5.2 complete, 2 points

BGP complete, 5 points

BGP Pingtests complete

12:40pm 6.1 complete, 3 points
12:40pm 6.2 complete, 1 point
12:44pm 6.3 complete, 1 point
skipping 6.4, 0/2 points

Multicast isn't working right, I may lose all 7 points here

1:06 7.1 complete, 2 points
1:09 7.2 complete, 1 point

IPv6 complete 3 points

1:17 8.1 complete, 2 points
1:36 8.2 complete, 1 point
1:36 8.3 complete, 2 points
1:36 8.4 complete, 2 points
1:36 8.5 complete, 2 points

QoS complete, 9/9 points

1:42 9.1 complete, 2 points
skipping 9.2
skipping 9.3
10.1 complete, 3 points
10.2 complete, 3 points
10.3 complete, 3 points
10.4 complete, 3 points

Grading
4.5 -2 points. I was close, need to play with the area command some more
4.8 -2 points. ip ospf authentication null
6.4 -2 points. I knew this--need to research ip pim nbma-mode some more
9.2 -3 points. Need more practice with reflexive acls to be mroe comfortable
9.3 -2 points. aaa authentication password-prompt, username-prompt, login local
10.2 -3 points. snmp-server tftp-server-list
11.1 -2 points. Need more pracitce wtih NAT

Total estimated score, 84

Sunday, February 3, 2008

IE Lab 5

And now it's time to change gears with an IE lab. I'm doing all the ones straight from the "recommended lab studying" from their resources page.

7:05am lab started
7:26am initial diagrams complete
7:55am final diagrams and readthrough complete--I may complete a mcast diagram later
8:04am troubleshooting complete, 2 points
8:12am 1.1 complete, 3 points
8:14am 1.2 complete, 2 points
8:32am 1.3 complete. It took me a bit to get inarp figured out. Needed a multipoint interface along with the interface-dlci command. Switching from subinterface p to m required a reboot as well., 2 points
8:36 1.4 complete, 2 points

Section 1 and troubleshooting complete. 11 of 11 points

8:41 2.1 complete, 3 points
8:53 2.2 complete, 4 points
9:00 2.3 complete, 3 points
9:02 2.4 complete, 2 points
9:12 2.5 complete, 4 points

Bridging and Switching complete, 16 of 16 points, 27/27 total

9:21 3.1 complete, 3 points
9:25 3.2 complete, 3 points
9:35 3.3 complete, 2 points
9:37 3.4 complete, 2 points
9:40 3.5 complete, 2 points
9:49 3.6 complete, 2 points
9:59 3.7 complete, 3 points
10:14 3.8 complete, 3 points

IGP complete, 20 points, 47/47 total

12:27 pingtests complete. A couple of redis conn needed and all was well

11:06 4.1 complete, 2 points
11:54 giving up on task 4.2. In the real lab I would have moved on much faster
11:59 task 4.3 complete, 3 points
12:02 task 4.4 complete, 3 points

BGP complete, 8/10, 55/57 total

Taking lunch

12:22 back from lunch
12:28 task 5.1 complete, 3 points
12:52 task 5.2 complete, 3 points
12:58 task 5.3 complete, 2 points
1:00 task 5.4 complete 1 point
1:07 task 5.5 complete, 2 points

Multicast complete, 12/12, 67/69 total

I'm pretty comfortable with IPv6 so I'm going to skip it

1:14 task 7.1 complete, 3 points
1:22 task 7.2 complete, 2 points
1:39 giving up on task 7.3, how to set the queue depth
2:04 task 8.1 complete, 3 points
2:09 task 8.2 complete, 3 points
2:17 task 9.1 complete, 3 points
2:19 task 9.2 complete, 3 points
2:29 skipping task 10.1, no idea
2:30 skipping task 10.2, no idea

Lab complete, 84/100. Barely passed, but I skipped IPv6 which would have been a relatively easy 7 points

Here's what I missed
Task 4.2--neighbor x.x.x.x remote-private-as
Task 5.2--I needed to use ip pim rp-announce-filter rp-list x group-list y on R1
Task 7.3--I should have trusted my instincts, it used the shape max-buffers command
Task 8.1--I should have used the established keyword on the telnet access list.
Task 8.2--I didn't even think of using a VACL
Task 10.1--Transport preferred non fixes the annoying dns lookup issues
Task10.2--I stink at privilege levels. Learned a little more though.

Saturday, February 2, 2008

H Continued

11:50 back from lunch
12:17 OSPF complete, 10 points
12:32 pingtests complete
12:42 BGP complete, 10 points
12:52 Router Redundancy complete, 8 points
1:04 Multicast complete, 9 points
1:40 IPv6 addressing complete, 8 points
3:45 had to take a break at about 2:30 for some other commitments. Now I ran out of time. I was most of the way through ipv6 routing, so I'll give myself 6 of 9 points.
I'll do QoS in notepad by hand
3:57 QoS completed, 5 points

Summary:
7 hours
97 points

The focus of this lab was obviously IPv6. I was disappointed I ran out of time because it was a pretty difficult IPv6 scenerio. I was picking things off one by one, just hadn't quite had it finished yet.

Interestingly, there was no ipv6 routing protocol running in between two ipv6 IGPs. I setup a tunnel to overcome this. The answers went with a default route and policy routing instead.