I’m finally back from RTP and have a stable enough Internet connection to finally write a post.  After my SP lab last week, I decided to visit some relatives in Charleston, SC to relax over the weekend before coming home.  I tried to post something on Friday, but my hotel wireless connection was terrible.  Anyways, read on for a recap.

Since the Thanksgiving weekend, I’ve been scrambling to get enough practice time in for the configuration portion of the lab.  Shortly a few days after committing payment to Cisco for the lab, the announcement for the OEQ or Core Knowledge came out which changed my studying strategy quite a bit.  At the time, I had just begun going through INE VOL2 labs before the Christmas holidays and so now I needed to come up with another game plan.  I gave myself a deadline to finish up the VOL2 labs 1 through 5 by New Years.  For the remaining 5 VOL2 labs, I was just going to read the solutions.  Once the new year began, I only labbed up mini scenarios and didn’t bother doing any full scale labs.  All I ended up doing was reading anything I could get my hands on regarding the SP lab blueprint (i.e. books, FAQs, blogs, Cisco white papers, articles, etc.).

Did all the reading help?  Yes, it did.  The set of OEQs that I received were pretty straightforward.  If you have some clue as to what you are doing in general with topics covered in the blueprint, you should be prepared.  Now I know that statement is vague and probably doesn’t really help you much, but the OEQs are really nothing to be concerned with at all.  I can’t speak for individuals who took the lab in the first 2 months, but I think the Cisco folks have finally figured it out where the OEQs are really ‘Core Knowledge’ type questions.  If I could make one suggestion to the Cisco developers, you should have the OEQs at the end of the lab.  The biggest complaint for many individuals that get a set of off-the-wall questions is they feel gypped having just forked over $1400 for only 30 minutes of completing the test.  What’s the point in continuing onward if you already knew you blew your chance at the start of your day?  Nothing you do in the configuration portion matters if you can’t get by 3 out of 4 questions.  IMHO, I think if the questions were at the end of the lab then test takers couldn’t complain since they would actually have to work through the entire day.

Unfortunately, because I spent so much time on reading, my speed was off with the configurations.  There was a lot of typing involved with my version of the lab. On top of that, I wasn’t fully rested going into the test as I would’ve liked.  I was a bit foggy having been up all night due to nerves.  Believe me, I exhausted myself before my flight out to Raleigh so I could just sleep when I arrived, but I was pretty wired and couldn’t stop thinking about 4 questions.  In the end, I fell short on the configuration end of the spectrum.

Here’s an outline on what I did for this attempt:

1) Read: Just try to understand the material you are reading.  I don’t think you need to memorize every little detail, but know the important subject matter.  Here’s a list of everything I read:
MPLS Fundamentals
MPLS VPN Architectures
MPLS VPN Architectures Volume II
Routing TCP/IP Volume I
Routing TCP/IP Volume II
Cisco FAQs
Cisco White Papers
RFCs

2) Choose a vendor workbook:  For my attempt, I used INE’s VOL1 and VOL2.  Keep in mind the material is very outdated but still relevant for this lab.  Everything you need to know is in VOL2, you just need to reference the Cisco documentation yourself to get a thorough understanding of the technology.  If I could make a suggestion to the INE folks, I think the only updates you should make for your products are:

-VOL1: Create some IS-IS labs with explanations.  I ended having to use my R&S OSPF, EIGRP, and RIP VOL1 lab scenarios to test out IS-IS.  IS-IS is extensive enough on the exam that it should be covered in your product.

-VOL2: I really liked what INE has done with the R&S and Security workbooks; they give you a brief explanation alongside the expected output.  We could really use the additional information to help reference materials for the OEQ.

3) Core Knowledge Simulator:  I ended up purchasing this product 1.5 weeks before the lab and only looked at it 2-3 days beforehand.  IMHO, the product just destroys your confidence all together because you feel like you’ve forgotten your CCNP studies.  You also get a false sense that you are required to know the granular details of the technologies.  Based on the OEQs I received, your questions are really off the mark and probably need to be scaled down just a bit.

4) Practice: I didn’t utilize the rack rentals as I had anticipated.  I ended up just using dynamips when I was labbing, which should be enough.  If you have the money to spend, go ahead and rent or buy equipment.  If you are on a shoe string budget and have a powerful enough workstation, then invest some time in dynamips or GNS3; the IOS code you should be running is 12.2S.  There’s definitely a difference in the feature sets when you are running 12.3T and 12.2S so you should be familiar with both versions.

Am I going to take a 2nd attempt?  That depends, having just checked the availability the next possible opening at San Jose is in September.  I don’t think I’ll be flying out to other locations anymore to test.  In fact, most of the tests will be running of SJ anyways (similar to the R&S format) and conducted at nearby Pearson Vue locations in the future so it doesn’t make sense to fly out (unless of course work pays for it and everything isn’t out of my own pocket).  There are other rumors that this lab will be retired and replaced by SP Operations.  I was told that for the month of July all lab testing sites will be blocked off completely to allow major changes to the lab testing facilities as well as when the announcements will be revealed.  If I can get another test in before June, I think I’ll donate more money to Cisco.  Until I can get a close enough date, I’ll just be enjoying my time away from all the stress:

-Catching up on all my shows on the DVR

-Toying around with JNCIE-ER or JNCIE-M/T

-Creating some mini-scenarios to help cover the lacking areas of technologies

-Playing basketball on the weekends again

-Networking at Interop, CiscoLive, etc.

Here are some additional notes I found while cleaning out my drafts.  I forgot to publish it when I was reading the book.

MPLS Fundamentals - Chapter 6: Cisco Express Forwarding

Overview of IOS Switching Methods
-Process Switching - An IOS process handles the switching of a packet
-Interrupt Switching - When packets arrive the interface processor interrupts the central CPU asks it to switch the packet according to a route cache or switching table
-ASIC - CEF table is programmed in ASICS so packets can be switched in hardware

Process Switching
-IOS process copies the packet to CPU memory and looks up destination IP in routing table
-Packets are switched out particular interfaces after TTL has been lowered and CRC has been recalculated
-Central CPU always looks at packet

Fast Switching
-An on-demand forwarding table
-1st packet is process switched; central CPU builds a cache
-Interrupt code will switch subsequent packets for the same destination
-Cache is not permanent
-Route cache has an outgoing interface, next hop, and Layer 2 Rewrite field
-Enabled with ‘ip route-cache’ interface command

CEF Switching
-Table is built in advance
-Only switching method that can label an incoming IP packet and forward it

CEF Components
-FIB - Also known as CEF table
-Adjacency Table - Responsible for MAC or Layer 2 Rewrite; ARP used to map Layer 2 addresses to IP

CEF Table
-Responsible for the Layer 3 forwarding decision
-Recursive prefixes are immediately resolved

CEF Operation
-When packet enters router, Layer 2 info is stripped off
-A lookup is performed on the destination IP in the CEF table
-A forwarding decision is made
-Layer 2 Rewrite allows router to put a new Layer 2 header onto the frame before switching the packet out the outgoing interface toward the next hop

Distributed CEF (DCEF)
-Can be used in a distributed manner with higher-end models (i.e. 7500, GSR 12000)
-Distributed CPUs handle forwarding of traffic without burdening the central CPU
-For 7500, the CEF and adjacency table resides on VIP
-For GSR 12000, the CEF and adjacency table resides on the line cards

CEF Switching in Hardware
-ASICs can forward packets at very high rates

CEF Load Balancing
-Per-packet - Round-robin packet per packet on outgoing links
-Per-destination - Destination and source IP addresses are hashed; hash is pointed to load sharing table

Labeling IP Packets by CEF
-CEF labels only the packets that are initially on the ingress PE router

Load Balancing Labeled Packets
-If MPLS payload is IPv4 packet, load balancing is done by hashing the source and destination IP address of the IPv4 header
-If MPLS payload is IPv6 packet, load balancing is done by hashing the source and destination IP address of the IPv6 header
-If MPLS payload is not an IPv4 or IPv6 packet, load balancing is done by looking at the value of the bottom label

This chapter is definitely more informative than the last one.  Anyways, here are some my notes.

MPLS Fundamentals - Chapter 5: MPLS and ATM Architecture

ATM Cell Format
-I.361 Layer
-Header - 5 bytes
-Payload - 48 bytes
-UNI Header - Contains 4 bits of Generic Flow Control (GFC)
-NNI Header - No GFC, ATM switches use 4 bits for VPI; contains Data/Mgmt, EFCI, and M-bit

AAL
-Layer between ATM and upper layer
-5 Categories
–AAL1 - connection-oriented; used for delay-sensitive services and circuit emulation
–AAL2 - connection-oriented; used for variable rate services
–AAL3/4 - connectionless; used for SMDS
–AAL5 - connection-oriented or connectionless; used for varying bit rate demands

Overlay Network
-Routers need to be interconnected in a full mesh and use an IGP for peering

Peer Model
-Routers are now edge LSRs connected without IGP adjacency
-MPLS encapsulated
-MPLS label value is mapped to VPI/VCI

Label Encoding
-Only top label is mapped to VPI/VCI
-Label stack is set to 0

Label Advertisement
-IGP and LDP cannot run directly over ATM interface and establish a neighborship; a control VC is needed
-Label Switched Controlled Virtual Circuit (LVC)
–Configure ATM interfaces to be Label Switching Controlled-ATM (LC-ATM) interfaces
–Encapsulation must be LLC/SNAP
-Tag Switching Controlled Virtual Circuit (TVC)

Downstream-on-Demand Label Advertisement
-ATM LSR only advertises a label when it is requested
-ATM LSRs use the Ordered LSP Control mode whereas non-LC-ATM routers use the Independent LSP Control mode
-Downstream ATM LSR only replies with a label if it has received a label for the prefix

ATM Switch Position
-Tail End Switch - means ATM LSR is egress
-Transit - ATM LSR between ingress and egress on the LSP
-Head End Switch - means ATM LSR is ingress

LDP Control Mode
-Independent - means an LSR immediately responds to a Label Request message from upstream
-Ordered - means that LSR only responds to the Label Request message from upstream when it received a response its Label Request message from its downstream LSR
-Ordered is default in IOS

Label Space
-Per-inteface label space is used for LC-ATM

Aggregate Labels
-Avoid aggregating labels on ATM LSRs when labeled packets must become unlabeled; serious performance impact

Non MPLS-Aware ATM Switches
-Run VP tunnels across the non-MPLS-aware ATM switches that will carry LVCs

Methods for reducing LVCs
-Reduce IP prefixes - Use a loopback and IP unnumbered
-VC-Merge - Reduces one VC per destination regardless of the number of upstream neighbors
-Map CoS classes - Map several classes to one Multi-VC TBR LVC type: available, standard, premium, and control
-Disable head end VCs - ATM LSR cannot function as edge ATM LSR
-Block Label Request - Blocks the signaling of the VCs

I had to read this chapter about 4 times last week to digest the material.  The delivery of the information needs to be restructured.  It was such a hard read for me because I found that the information seems to jump around all over the place.  Unlike the previous chapter where you actually learned how the technology works, this chapter is designed to just show you how to implement features within LDP.  IMHO, you’re probably better off supplementing your studies with reading RFC 3036 to get a better understanding of LDP.  Anyways, here’s some of my notes after reading.

MPLS Fundamentals - Chapter 4: Label Distribution Protocol

Discovery
-Hello messages (UDP 646)
-LDP ID is a 6-byte field; LDP ID = LSR ID (4 bytes) + Label Space (2 bytes)
–If last 2 bytes are zero, label space is platform-wide or per-platform
–If last 2 bytes are non-zero, label space is per-interface and multiple LDP IDs are used (i.e. LC-ATM)
-LDP ID needs to be present in routing table of neighbor routers, otherwise LDP session is not formed

Session Establishment
-Hello messages (TCP 646)
-Negotiation of session parameters (i.e. timers, distribution method, VPI/VCI, and DLCI)
-LSR modes: advertisement, label retention, and LSP control mode

Label Withdrawing
-Label withdrawn if local label changes (i.e. implicit NULL –> non-reserved label)

Notifications
-Error - sending and receiving LSR should terminate session
-Advisory - LDP session info from peer
–Signaled Events
—Malformed PDU
—Type-length-value (TLV)
—Session keepalive timer expiration
—Unilateral session shutdown
—Initialization message events
—Events resulting from other messages
—Internal errors
—Loop detection
—Miscellaneous events

Target LDP Session
-LDP session between LSRs that are not directly connected

LDP Authentication
-Implement MD5 digest

LDP Autoconfig - Easier to use than configuring each interface separately

LDP-IGP Synchronization
-When LDP session is broken on a link, IGP still has that link as outgoing; packets are still forwarded out of that link
-Packets become unlabeled when LDP is broken; LSR is unable to forward packets and drops them
-LDP-IGP Sync ensures that link is not used to forward unlabeled traffic when LDP session is down
-OSPF is only supported IGP
-After LDP session is established and label bindings are exchanged, IGP advertises link with normal metric and traffic is label-switched across interface

LDP Session Protection
–Flapping links are detrimental because LDP and IGP need to time rebuild neighborship
–Utilizes targeted LDP sessions for protection