CCIE Trek

A blog of Jeff Rensink's trek to the CCIE summit (again)

Archive for November, 2008

Study Update

Posted by jrensink78 on November 30, 2008

I hope everyone had a nice Thanksgiving.  Mine was unfortunately mildly interrupted by a recent virus outbreak.  Fortunately my company was not hit, but we had to deal with patching up PCs that weren’t getting their regular updates.  Didn’t take up a whole lot of time, but it was not what I wanted to have to keep tabs on during the holiday break.

Studying is going pretty well.  I’m nearly half way through my second run-through on all of my materials.  I should hopefully be done in a couple of weeks.  So I should be on track to take my first (and hopefully only) shot at the written test by the end of the month.  My only concern is that I don’t quite know what level of difficulty to expect on the test.  I do have the practice test that came with the Cisco Press Exam Cert Guide.  I’m hoping that will be a fairly good indicator.

If there by chance happen to be any readers out there that have passed their written test, I wouldn’t mind any suggestions on how to know when you are ready for the written test.  I do know one method, but it costs $350.

Posted in Study | Tagged: , | Leave a Comment »

NTP basics- overview

Posted by jrensink78 on November 25, 2008

Well, I was able to get my NTP stuff straightened out, so here is the overview that I wanted to write.  NTP is fairly straight forward, but there are a few tricky parts in terms of how it works on Cisco devices (or at least I thought so).  So hopefully this will make things clear.

The first thing to know about NTP is that Cisco devices will only learn time from a device that has synchronized to an existing time source.  So in order to get the ball rolling with NTP in your Cisco network, you have 3 main options

  • Synchronize to an external NTP server with one or more of your Cisco devices
  • Synchronize to an internal NTP server with one or more of your Cisco devices (maybe a Linux box acting as a time server)
  • Use the ntp master command on one of your Cisco devices to have it “synchronize” with itself.  In a Cisco lab, this is really your only option.

Now that we have at least one device synchronized, we can start advertising time throughout the network.  There are two main modes of advertising time.  Client/Server mode and Symmetric Active (or Peer) mode.  It’s important to know how each of these work.  Before I get into the details, here are the 2 commands that we’ll be using.

ntp server (IP address) will specify a device to learn time from (used in client/server mode)
ntp peer (IP address) will specify a device to learn time from, as well as a device that time can be served to (used in peer mode)

Now that you know the basic commands, here is how things will operate.  By default, if a Cisco device has synchronized its time, it will allow any other device to learn time from it.  If a device uses the ntp server command, it will learn time from the specified device, but will not allow that device to learn time from it.  If a device uses the ntp peer command, it will learn time from the specified device and also allow the device to learn time from it.   Here are some examples to illustrate all of the different permutations.

In the following examples, Router A has synchronized its time and router B has not.  Router B will attempt to learn time from Router A.

  • Router B specifies Router A as its server, Router A does not specify router B as anything.  Result= Router B gets time from Router A.
  • Router B specifies Router A as its peer, Router A does not specify router B as anything.  Result= Router B gets time from Router A.
  • Router B specified Router A as its server, Router A specifies Router B as its peer.  Result= Router B gets time from Router A.
  • Router B specified Router A as its peer, Router A specifies RouterB as its peer.  Result= Router B gets time from Router A.
  • Router B specified Router A as its server, Router A specifies RouterB as its server.  Result= Router B will not get time from Router A.
  • Router B specified Router A as its peer, Router A specifies RouterB as its server.  Result= Router B will not get time from Router A.

So basically it comes down to the following in terms of allowing other devices to learn time from a router (assuming the router is synchronized).

  • The router does not specify the other device as a server or peer= it will serve time to the other device
  • The router specifies the other device as a peer= it will serve time to the other device
  • The router specifies the other device as a server= it will not serve time to the other device

So knowing this, what might be a good way to set up NTP in your  network?  First you’ll want to start off with one or more external time sources to learn from.  The lower the stratum number (measurement of accuracy), the better.  Have a handful of core network devices use these as ntp servers.  Next, have all of these core network devices specify each other as ntp peers.  That way, if any of the core network devices lose connection to their servers, they can keep each other on synchronized time.  Finally, have your other devices use these core devices as their servers.

Depending on the size of your network, this might be overkill, or you’ll need a more expanded solution.  But it’s a good starting point in terms of how to build a heirarchical NTP network.

Posted in Technology Overview | Tagged: , | Leave a Comment »

What happens to a packet when it gets routed?

Posted by jrensink78 on November 24, 2008

I was planning on writing up an overview on NTP, but I ran into some inconsistencies between what I was reading/watching and what I was able to reproduce in a lab.  So I’m going to table that for now and talk about what happens to a packet as it goes through the routing process in and Ethernet network.  This is a high-level overview included in the CCIE R&S Official Cert Guide from CIsco Press.

  1. When a router receives a frame, it checks the Frame Check Sequence (FCS) to see if the packet encountered any errors in its trip.  If the FCS check fails, the packet is dropped.  The router does not attempt to recover the packet.
  2. IF the FCS check passes, the router reads the Ethernet Type field and extracts the packet from the frame.  The data link header and trailer is discarded
  3. The router looks at the destination address of the packet and finds the most specific match for it in its routing table
  4. The routing table entry will have the applicable information of the outgoing interface and next hop needed to build a new data link frame
  5. Before creating the frame, the router decrements the IP header TTL field and recomputes the IP header checksum field (as a result of the TTL field change)
  6. The router encapsulates the packet with a new data link header and trailer to create the new frame
  7. The frame is send out the appropriate interface on to the next hop.

Again, this is pretty high-level, but there are a couple of good points to remember.

  • The data-link header and trailer only survive a single hop.  Each router strips the old header/trailer and creates a new one.  As a result, source and destination MAC addresses change per hop.
  • The IP header checksum will change at each hop to compensate for the TTL field changing.
  • The layer 4 headers (TCP, UDP, etc) and data payload remain unchanged throughout the process.  So a checksum change for the whole IP packet is not needed.

Posted in Technology Overview | Tagged: , | Leave a Comment »

Dynamic Trunk Protocol (DTP)- Overview

Posted by jrensink78 on November 20, 2008

Here is a quick overview/cheat-sheet of Dynamic Trunk Protocol (DTP).  The table below shows which combination of port modes will create a successful trunk via DTP.  (and before anyone says anything, I do realize that the modes with no-negotiate do not actually use DTP)

Access + No-negotiate Access Dynamic Auto Dynamic Desirable Trunk Trunk + No-negotiate
Access + No-negotiate No No No No No No
Access No No No No No No
Dynamic Auto No No No Yes Yes No
Dynamic Desirable No No Yes Yes Yes No
Trunk No No Yes Yes Yes Yes
Trunk + No-negotiate No No No No Yes Yes

Here are a few important points regarding DTP.

  • The default port mode on 3550 switches is Dynamic Desirable.
  • The default port mode on 3560 switches is Dynamic Auto.
  • If both switches support ISL and Dot1q trunks, and neither is specified, ISL will be preferred.
  • The no-negotiate option is used when you do not want to send out DTP frames.
  • The no-negotiate option is only usable with the Access and Trunk modes.

I have seen Cisco documentation that Dynamic Auto is the default switchport mode.  The Cisco Press Exam Certification Guide says that Dynamic Desirable is the default mode.  It seems to be depndant on the switch model.  New models appear to use Dynamic Auto.  So I guess I would stick with that as the default mode of a switchport if you were asked on a test (unless a specific model is mentioned).

Posted in Technology Overview | Tagged: , , | Leave a Comment »

VLANs and VLAN Trunking- Notes

Posted by jrensink78 on November 20, 2008

Here are my notes on the VLANs and VLAN Trunking chapter of the Cisco Press Exam Certification Guide book.  This is foundational knowledge for switching that needs to be known backwards and forwards.

Best practices dictate a 1-to-1 relationship between VLANs and IP subnets

For a VLAN to be operational, the following must be true

  • VLAN has been created
  • Switchports must be assigned to VLAN

VLANs can be created in VLAN Database mode (depreciated), global config mode, and interface config mode

Private VLANs

  • Requires a Primary VLAN and one or more Secondary VLANs
  • Ports in a primary VLAN are promiscuous and can talk with any secondary VLAN ports
  • Secondary Community VLAN ports can talk to other community ports in the same secondary VLAN and ports in the primary VLAN. Need a community secondary VLAN for each community group.
  • Secondary Isolated VLAN ports can only talk to ports in the primary VLAN. Only need one isolated secondary VLAN.

VTP Modes

  • Server
    • Can create/edit VLANs (1-1005)
    • Can act upon and originate VLAN updates
    • Default VTP mode
    • Stores info in vlan.dat file on flash
  • Client
    • Can learn VLANs (1-1005)
    • Can act upon and originate VLAN updates
    • Stores info in vlan.dat file on flash
  • Transparent
    • Can create/edit VLANs (1-4094)
    • Can not originate or act upon VLAN updates
    • Will forward on received updates from other switches
    • Stores info in vlan.dat file on flash  and also in config

Switches are in server mode by default.

They do not send out advertisements until they have a domain configured.

They will learn a domain from the first advertisement that they receive.

For switches to be able to update each other, VTP domain and password must match.

VTP updates only sent over trunks

VTP version 2 really only needed for Token Ring support

VLANs 1, 1002-1005 are special and cannot be deleted

ISL trunk adds a 26 byte header and a 4 byte trailer.

ISL header destination address is 0100.0C00.0000 or 0300.0C00.0000

ISL is the preferred trunking encapsulation if both ISL and 802.1Q are supported

802.1Q adds 4 byte tag after source address field. First 2 bytes is an ethernet type value of 0×8100.

802.1Q supports native VLAN concept (does not insert a tag).

Dynamic Trunk Protocol (DTP)

  • Trunk- always sets up a trunk
  • Desirable- will set up a trunk with Trunk, Desirable, and Auto
  • Auto- will setup a trunk with Trunk and Desirable
  • Access- will not setup a trunk
  • No-negotiate- used with Access and Trunk. Does not negotiate using DTP. If used with Trunk, the other side must also be Trunk in order for a trunk to be fully operational

Trunking on routers

  • Routers do not support DTP. So trunk must be statically configured on both ends.
  • Typically uses subinterfaces for each VLAN on the router
  • Uses the encapsulation command under each subinterface
  • Native VLANs configured on subinterfaces require the native keyword in the encapsulation command
  • If native VLAN is not configured on a subinterface, the router assumes it is on the physical interface. In this case, the physical interface does not need the encapsulation command

802.1Q-in-Q trunking

  • Allows a service provider to preserve 802.1Q VLAN tags across a WAN service
  • CDP and VTP traffic passes transparently over the Q-in-Q service

Posted in Notes | Tagged: , , | Leave a Comment »

Ethernet Basics- Notes

Posted by jrensink78 on November 20, 2008

Here are my notes on the Ethernet Basics chapter of the Cisco Press Exam Certification Guide book.  This is pretty much one of those chapters that is all theory and not very helpful in relation to the lab.  But it’s stuff that everyone should know.

Also, an FYI on how I’ll categorize my future posts.  “Notes” posts will be my own study notes cut and pasted into the post.  So they won’t be real descriptive or polished.  “Overview” posts will be focused on a certain topic and will be written a more reader-friendly manner.

10/100 Ethernet uses pins 1-3 and 6 for communications.

Pins 1-2 are transmit and pins 3,6 are receive for a PC/Router (switches are opposite)

Auto-MDIX on switches can compensate for using wrong cable types (straight-through or cross-over)

Speed/duplex auto-negotiation

  • Cisco switches sense speed using the Fast Link Pulses (FLP) of the auto-negotiation process
  • If one side has auto-negotiation turned off, the other switch can still detect speed based on incoming electrical signal
  • Duplex auto-negotiation requires both sides to participate
  • If one side does not participate, 10/100 links default to half-duplex and Gig links default to full
  • To turn off auto-negotiation on a switch port, statically set a speed/duplex setting in the interface config mode
  • Cannot set duplex on an interface until speed has been set
  • CDP can detect duplex mismatches and send notification, but cannot remedy

CSMA/CD process

  • Device with a frame to send listens to the wire and waits for a free line (no carrier signal sensed)
  • When the line is free, the device starts sending the frame
  • Sender listens to make sure no collision occurred
  • If there was a collision, all devices that sent a frame send a jamming signal
  • After the jamming signal is complete, each device that sent a frame that collided set a random back-off timer
  • Once the timer expires, the devices can begin sending again

Ethernet hubs

  • Operate at layer 1
  • Repeat (regenerate) signals to improve cabling distances
  • Forward data received on one port out all others
  • Creates a single collision domain

When switches receive multiple frames of different switch ports, they stores frames in memory to prevent collisions

NICs operating in half-duplex mode use loopback circuitry when transmitting a frame. This loops the transmitted frame back to the receive side of the NIC, so that when the NIC receives a frame over the cable, the combined loopback signal and received signal allows the NIC to notice that a collision occurred

In switch interface stats, collisions are detected in first 64 bytes. Late collisions are detected after 64 bytes have been sent. Deferred packets mean that the half-duplex switch port waited until it was not receiving data to send it.

Ethernet type fields

  • Ethernet DIX
    • 2 byte Type field
  • 802.3
    • 1 byte DSAP
  • 802.3 with SNAP header
    • 2 byte type field in SNAP header, DSAP of 0xAA

Multicast packets identified by I/G bit being a 1 (8th bit of the address)

U/L bit (7th bit) identifies if address is vendor assigned or locally assigned

Switch MAC address (CAM table) aging timeout is 300 seconds by default

802.3u defines 100MB Ethernet over fiber and copper

802.3z (optical) and 802.3ab (copper) define Gig Ethernet

Switch internal processing

  • Store and forward- switch fully receives frame before forwarding
  • Cut-through- switch performs table lookup once destination address field is received. Does not allow switch to drop frames that fail FCS check
  • Fragment free- like cut-through, but waits to receive first 64 bytes before forwarding. Should avoid forwarding frames damaged by collisions

Posted in Notes | Tagged: , , | Leave a Comment »

Updated study progress report

Posted by jrensink78 on November 19, 2008

Today is a day of mile markers in my studying.  Today marks the end of my second month of preparation towards my CCIE.  Another mile marker is that I finished going through all of my material for the first time.  That would include the Cisco Press Exam Cert Guide, Routing TCP/IP vol 1 and 2, and all of the IP Expert BLS videos.  Yet another mile marker would be hitting 200 hours of studying.

I have been having a hard time staying on track as of late.  I do say, I’m looking forward to getting past the written test so I can start prepping for the lab.  Spending the bulk of my time reading and watching videos is making the study hours go by slowly.  Time seems to fly when I’m labbing it up.  But I’m drawing a line in the sand and getting back into the swing of things.

So in the coming month or 2, I’ll be going back over all of the material.  I’ll also be compiling notes and cheat sheets for all of the subjects in the written blueprint.  As I do, I’ll be posting those up on the blog.  Hopefully they’ll be helpful to someone.  So I should be getting back into rhythm of posting some content every couple of days again.

Posted in Study | Tagged: , | Leave a Comment »

Internetwork Expert CCIE 2.0- final thoughts

Posted by jrensink78 on November 15, 2008

Now that I’ve been able to view the CCIE 2.0 presentation, I thought that I would share my final thoughts on the program.

Here is what I like about the new CCIE 2.0 program.

  • No cost increase over the previous end-to-end program for the self-paced program.
  • More training material for the same price with the addition of the Open Lecture and Lab Meet-up series
  • Adaptive assessment exams
  • Training guidance based on assessment exam results
  • Access to direct instructor interaction throughout the course of your lab preparation (using the instructor led option)
  • Even with the new adaptive training focus, there is nothing stopping you from studying under the old method if you want.  So you are not forced to change.

What I don’t like.

  • Haven’t really seen anything yet

So far all of the changes that I have seen have been pretty positive.  I somewhat wonder about the instructor led version.  In order to get your money’s worth from that, you would need to attend the online classes and open instructor times.  Based on the current schedule, there are 3 open lectures and one lab meet-up per week.  I believe there is also one open instructor time per week as well.  They also appear to be all week-days.  So there are a lot of opportunities, but you are at the mercy of the schedule.  You are also at the mercy of the subjects covered.  So you either attend classes on subjects that you are not focusing on at the time, or change your study schedule to line up with the classes.

Outside of that, I like what I see.  I wasn’t planning on purchasing IE’s end-to-end program before.  But now I’m definitely leaning towards purchasing the CCIE 2.0 program.

Posted in Study Materials | Tagged: , | Leave a Comment »

CCIE 2.0 details released

Posted by jrensink78 on November 11, 2008

I was cruisin’ through my CCIE blogs this evening and spotted that Internetwork Expert posted a write-up of their CCIE 2.0 program on their blog.  You can see the post here.  A couple of the big new details are the format and pricing of their Open Lecture Series and Lab Meet-ups.

The open lecture series will be regular online classes that meet multiple times per week.  Students have the ability to interact with the instructors here.  The lectures will be available in a CoD format afterwards.  Along with this, instructors will also have Open Instructor Time, which are equated to office hours for a college professor.  Students can pop in and asks questions of the instructors on any topics.  The cost of the online version of the open lecture series is $1495, and the CoD only access is $995.

The lab meet-up series will have instructors “configure, verify, troubleshoot, and explain in detail the complex questions and solutions contained in our CCIE Routing & Switching Lab Workbook Volume II series in real-time.”  Students will be able to interact with instructors in the online version.  These will also be available in CoD format afterwards.  Cost for this series is the same as the open lecture series.  $1495 for online, and $995 for CoD only.

Be sure to join the online class detailing the CCIE 2.0 program tomorrow at 11AM PST.  If you can’t make it, a CoD version will be available afterwards.

Posted in Study Materials | Tagged: , , | Leave a Comment »

IP Expert end of year sale

Posted by jrensink78 on November 5, 2008

I received an email notice that IP Expert is having end of the year specials on most of their CCIE products.  You can see the list of deals here.  So if you wanted to pick up some workbooks, Blended Learning Solutions, or schedule a bootcamp, now would be a good time.

Posted in Study Materials | Tagged: , , | Leave a Comment »