Introduction

Having already covered physical presence intrusion, detection, monitoring, surveillance, logging and privacy issues and the reason why we sometimes need to take a step back and view the situation from another perspective it is time to continue our through the eyes of a machine view of physical security.

Naming Conventions

The planning of your naming conventions for infrastructure and other network devices and assets in a logical and meaningful way is an aspect of network infrastructure that is too often not given just due care and attention. One of the most important reasons as to why you should do this is simply “so things don't get out of hand”.

“Stay on top of your devices; don't let them get on top of you”, is a theme that you will come across many times in the world of security, communications and networking. And it all starts with names.

The question that I am going to challenge you with here is what does the following string mean “F1R4S2S3CCS29501425P11F”? Read on and all will become clear.

Why Names?

Because we are humans and humans like to give things names in order to make some sort of meaning out of the world around us. Take the Internet for example: we get from place to place on the Internet by using a naming convention known as the Domain Name System or DNS for short.

Domain Name System (DNS)

Think of it as a telephone book that lists a whole pile of “human friendly” names and matches them to corresponding Internet address or IP Addresses pretty much in the same way as the white pages telephone directory that we all have come to know over the years. We humans find it easier to think of names rather than numbers. It's just the way we are.

There is no doubt about it; computersight.com is definitely more manageable than 200.184.219.176 for example. No!! This is not the IP Address for computersight.com; I just made it up, so to whoever actually owns it I apologize if a whole bunch of people get a wrong number. I will be covering DNS in another article.

Building Your Own Naming Convention

When it comes to naming conventions the question I get asked most is “How do you do it?” By “it” the enquirer wants to know how I go about creating a naming convention. It's not really that hard and I will show you now one way in which you can begin to build your own structured secure naming conventions.

Breaking the problem down I have found that most people really only want to know one basic thing and then they are quite fine to finish the job on their own. It's the big question of “Where do I start?” The best way to answer this is by using an example; so here we go:

Defining the Situation

Suppose you have 4 domain controllers, 10 web servers, 6 routers, 20 high-end switches, 100 workgroup switches that use transparent bridging, 3 mail servers, 5 file servers, 2 database servers and untold numbers of workstations and peripherals.

The first question that pops into the minds of most people; including network administrators, especially those without experience of this type of situation is: “Naming and naming conventions, where do I start?”

Defining the Beginning

Well as stupid as it may at first sound, the answer is of course at the beginning.

Which brings us to “How do I find and define the beginning?”

In this case the beginning is a physical thing. This means that we will be able to construct our new naming convention based on physical properties. The reasons for doing this are partly for ease of reference and partly for solidarity.

Physical infrastructure and devices have a tendency to be relatively stable in terms of their outward physical characteristics and location. Routers and servers do not go on walk-about all of their own volition. Rack-mounted devices are even more unlikely to wander. The rack itself; if bolted to the floor and/or wall or ceiling also makes it hard for physical infrastructure and devices to wander.

So what are the types of physical characteristics that we can take advantage of to make our naming systems and conventions easier to create and administer?

Defining the Physical Basics

The first thing to do is; as mentioned above, bolt and lock all physical infrastructure and devices down securely. Once done this has been done you can be confident that they will remain where they are. You now have your starting-point; that is, you have now created a “center-of-the-universe” reference base at least for this network.

The next thing to do is to find suitable aspects and physical attributes of our devices that would be suitable to use in our new naming convention. The question that we need to ask ourselves at this point is “What attributes should I use and where do they fit into the big picture?”

Defining a Hierarchy

In the example that we are working with here we have a number of different classes and types of devices as well as a whole bunch of physical infrastructure components such as cabling, racks, shelves etc. We also have communications and networking devices including routers and switches. In addition they are a number of servers. So let's put them into some form of structured order.

Humans find it easiest to address and manage large numbers and large numbers of individual items when they are given some sort of structured order and when that structured order inherently defines the relationships between the individual units, groups of units and the entire system of units as a collective entity.

So let us build our naming convention on a device and physical location hierarchal structure. At the top of this hierarchy are the core and infrastructure components of our network. The next layer down will be the distribution devices and infrastructure and then comes the local and peripheral devices and infrastructure components.

The biggest distinguishing feature between all of these assets is the type of service(s) that they deliver. Never forget networking and communications are all about the delivery of services when requested.

Top Level Entities

The devices that will be placed at the top level of a physical naming convention are those components that house other components. In our scenario this means the racks, their shelves and slots. At this point our most pressing concern is with the identification of specific physical locations.

Creating a naming convention that has the built-in capabilities of locating a device without even knowing the type of device that is physically located at this site will deliver your first layer of physical level naming convention security and redundancy. We will add the more device specific attributes shortly.

So Rack number 4, Shelf number 2, Slot number 3 definitely and unambiguously defines a specific physical location within our network but let's face it. This is a clumsy cumbersome name but its meaning is clear. Our next task is to make this clear and precise name less unwieldy. We shall do this by using the age old technique of contraction.

Facility number 1, Rack number 4, Shelf number 2, Slot number 3 becomes: F1R4S2S3. Definitely a lot easier to use at a glance and for those in the “know” a very precise physical location has been defined. Yet those not in the “know” are going to start having difficulties figuring this out. Given time they just might.

So we are going to make their job of cracking our simply naming convention system a lot harder by adding some extra detail that will assist us in knowing that the device that is currently at any given physical location is in fact the device that is meant to be there.

In this example physical naming convention the label; or tag if you prefer, of F1R4S2S3 would most definitely allows us to identify and locate in a very short period of time any specific device that is housed in this facility without prior knowledge of the device or even what type of device it is.

You will also note; that in Table 1 Naming Convention Hierarchy (above), I have not used building or room numbers that may be displayed publically. Instead I used “F1” to mean facility one which could be located anywhere within your organisation's complex. The communications, networking and security staff will all know that the “F1” refers to major central facility one.

You could of course have called it “N1” indicating that it is networking center one. The reason that I have not done so in this example is because we are looking to the future and I do mean the very near future.

Unified Communications and Network Convergence

Unified communications and networking convergence mean that it won't be too long before there will be no really clear demarcation point between networking and communications devices and infrastructure. Devices will be capable of and actually performing both functions.

IP telephony (VoIP) enabled LANs technologies and rollouts also add more weight to this being the norm rather than the exception in the years to come. So we might as well start thinking about this now and design our naming conventions to suit. Anyway I think you will be able to come up with your own system now that you have the knowledge of how and where.

Adding the Detail

In our example naming convention we have started with the entity that contained the most other entities: The Facility. Then we used the next sub-entity which also contained many other entities but with fewer sub-entities than the parent: The Rack. Then came: The Shelf, followed by: The Slot. Table 1 above shows this and how a Top-Down hierarchal system such as this works in the practical sense.

It is important that at the moment it makes absolutely no difference is actually located at the physical location of F1R4S2S3. Simply going here will get you to the device currently located here. But is it the “right” device?

This is where the next part of our naming convention comes into play. From a physical security stand-point it would be nice if we could not only get to the correct location but identify the device that should be there and compare this with the device that is actually there. In other words; what we need is a naming convention with a built-in cross-check, cross-referencing system. Here is how this can be done.

Built-In Device Confirmation

We are going to take advantage of the physical naming and labeling systems used by the manufacturer of the device and work them into our naming convention in this way will be able to distinguish any specific device from among the hordes that we are administering. In this aspect “human friendly” is a must.

Don't get me wrong. I do not mean friendly to every human just those “in-the-know”. We really don't care how much confusion we create for those not “in-the-know” because we don't want them to know. This is where the art and experience of creating naming conventions lies.

Mixing Alpha-Numeric Characters

You have already seen part of the way that I use most often to do this by creating a naming convention that uses a mix of alpha-numeric characters. Pretty much like they say you should do when creating authentication passwords.

Here is where we get to the device specific element of our name. We could identify a Cisco® Catalyst 2950 switch for example by using CCS29501. Here the CCS = Cisco® Catalyst Switch, the 2950 tells us that it is a 2950 series model and the last 1 tells us that it is switch 1. Remember we may have a number of the same series devices so it is handy to be able to tell them apart. I usually just use the last three or four digits from the devices serial number.

If you wanted to identify a specific port then I would use the same port identification convention as the manufacturer. Once again most manufacturers including Cisco® print this information on the device either above, below or next to the actual port.

So our new device name using our new naming convention would be F1R4S2S3CCS29501425P11F. I will write this out in full and then I think you will have the basic idea of what we have just done.

F1 = Facility 1, R4 = Rack 4, S2 = Self 2, S3 = Slot 3, CCS29501425 = Cisco Catalyst Switch 2950 series unit 1425 and P11F = Port 11 of the Front module.

Depending on your specific situation you can change this to suit yourself and your situation as desired. Now that you know the meaning behind the naming convention F1R4S2S3CCS29501425P11F seems as plain as day.

To someone; not-in-the-know, this jumble of alpha numeric characters is really quite formidable. Most of the time; those with malicious intent would simply give up and not even try to decipher the meaning of this string of characters.

It is in this way that we can quickly locate specific resources and components of resources. If you now the device name you can quickly go to it and check to may sure that the correct peripheral in another building is plugged into the correct port.

Network Convergence Implications

This is becoming even more important considering the convergence of networking and communications technologies that we are seeing today. Now the network administrator is performing a lot of tasks that were once the providence of the telephone guy. Not so anymore.

Develop and Maintain a Naming Convention Policy

The final task will as always be to create thorough documentation as you go. On the other hand the development and implement of an appropriate Physical Naming Convention Policy would be the first thing that you would do.

Coming up in the Physical Security Guide series are the following topics and concepts:

• Labeling, Checklists and Label and Checklist System(s) Security
• Drilling, Rehearsal, Role Playing Scenarios and Proof-of-Concept Implementations
• Surviving an Audit and Surviving Users
• The Physically Static Nature of Core Network Infrastructure Components
• Physical Location and Placement of Wiring Closets, Infrastructure Cabling and Cabling in General
• Mission Critical Systems, Rack Mounted Systems and Servers

So until next time enjoy!!

Let us have a quick look at some other essential information about protocols and the standards organizations that ratify them.

Protocol Converter

A protocol converter is a device/program which translates between different protocols which serve similar functions (e.g., TCP and TP4). [Source: RFC1392]

Protocol Data Unit (PDU)

Protocol Data Unit (PDU) is the name that the International Standards Committee uses for packet. [Source: RFC1392]

Protocol Standards Organisations

Here is a brief summary of the various bodies that produce and ratify the various communications and networking standards that we have been discussing. If you want to learn more about them just go to their websites and encyclopedic volumes of information will be at your disposal. I have included the links (URL) for each of these standards organisations below.

Internet Engineering Task Force (IETF) - The IETF is an international community of network designers, operators, vendors, and researchers working together to better facilitate the smooth operation of the Internet while advancing the evolution of its architecture.

Nearly all recent protocols for Internet communications have been assigned by the IETF with the IEEE and ISO handling the others.

IETF Mission Statement - The IETF Mission Statement is documented in RFC 3935

IETF Workgroups - Much of the work done by the IETF is carried out by different workgroups; with each focusing on their particular specialty. These workgroups are organised by topic (routing, transport, security etc.).

Communications - Mailing lists are used extensively by the IETF and its various sub-groups and committees.

Internet Architecture Board (IAB) - The purpose of the IAB is to oversee the architectural work of the various IETF working groups

URL: Ietf

Institute of Electrical and Electronics Engineers (IEEE) - Responsible for many other protocols including some Internet protocols. Their primary focus is on communications protocols from a networking perspective. This includes internetworking; meaning from one network to another. Hence the Internet gets in on the act.

The most widely know series of protocol standards that the IEEE has produced are the 802 DOTS (802.xx specifications). For example the 802.3 standard is all about Ethernet while the 802.11 specifications are standards concerning wireless networks.

URL Ieee

International Organisation for Standardisation (ISO)- The world's largest developer and publisher of International Standards. ISO is a non-governmental organisation comprised of a network of the national standards institutes of 157 countries. There is only one member per country and a Central Secretariat in Geneva, Switzerland coordinates the system.

URL: Iso

World Wide Web Consortium (W3C) - W3C is an international consortium where member organizations, a full-time staff, and the public work together to develop interoperable technologies such as: specifications, guidelines, software, tools and web standards.

Mission - The W3C have stated their mission to be: “To lead the World Wide Web to its full potential by developing protocols and guidelines to ensure long-term growth for the Web.”

In order to achieve their goal of one Web, specifications for the Web's formats and protocols must be compatible with one another and allow (any) hardware and software used to access the Web to work together.

W3C designs and promotes interoperable open (non-proprietary) formats and protocols to avoid the market fragmentation of the past.

URL: w3c

Internet Assigned Numbers Authority (IANA) - IANA is the central coordinator for the assignment of unique parameter values for Internet protocols.

IANA is operated by the Internet Corporation for Assigned Names and Numbers (ICANN) and is responsible for the global coordination of the DNS Root, IP addressing, and other Internet Protocol resources.

IANA is chartered by the Internet Society (ISOC) to act as the clearinghouse to assign and coordinate the use of numerous Internet protocol parameters.

URL: iana

Internet Corporation for Assigned Names and Numbers (ICANN) - ICANN was formed in 1998. It is a not-for-profit partnership of people from all over the world dedicated to keeping the Internet secure, stable and interoperable. It promotes competition and develops policy on the Internet's unique identifiers.

To reach another person on the Internet you have to type an address into your computer - a name or a number. That address has to be unique so computers know where to find each other. ICANN coordinates these unique identifiers across the world. Without that coordination we wouldn't have one global Internet.

URL: icann

International Telecommunications Union (ITU) - ITUis the leading United Nations agency for information and communication technologies. As the global focal point for governments and the private sector, ITU's role in helping the world communicate spans 3 core sectors

ITU-R - Managing the international radio-frequency spectrum and satellite orbit resources protocols and formats for is at the heart of the work of the ITU Radio Communications Sector (ITU-R).

ITU-T - The ITU-T handles telecommunications protocols and formats for the public switched telephone network (PSTN).

ITU TELECOM - ITU TELECOM brings together the top names from across the ICT industry as well as ministers and regulators and many more for a major exhibition, a high-level forum and a host of other opportunities

ITU-D - Established to help spread equitable, sustainable and affordable access to information and communication technologies (ICT).

URL: itu

The Internet Society (ISOC) - ISOC is a nonprofit organisation founded in 1992. The Internet Architecture Board (IAB), Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG) are all chartered by the Internet Society (ISOC)

URL: isoc

Request for Comment (RFC)

These are the documents in which the IETF formally documents in detail the various protocols, standards and specifications for Internet communications technologies and protocols.

No Rewrites or Modifications

Once an RFC that formerly details and documents any protocol or part thereof has been published there will be no further alterations, amendments or any other changes made to that document; period!

New RFC Documents

If the situation eventuates that for whatever reason a protocol needs to be changed, amended, enhanced, extended, etc. then a new document that formally recognizes this will be prepared and once ratified it will be published.

Acknowledgements

Documents that formally specify the standards for any given protocol will acknowledge any other protocols referencing the appropriate RFC documents and state that these protocols and specifications have now been superseded by this new protocol and standard.

Converging Standards

As the Public Switched Telephone Network (PSTN), radio systems, and Internet converge, the different sets of standards are also being driven towards technological convergence. Unified communications is here to stay. So we might as well get used to the fact and make it work to our advantage.

Effective Communications

In order for effective communications to occur we all need to agree upon the protocols that we will use. We also need to be in agreement concerning how these protocols will be designed, built/structured and implemented.

It was for these reasons that a consensus needed to be reached before we could have a true global communications system such as the Internet as we know it today. Out of this need a number of different and for once not opposing protocol standardisation organisations were born.

These organisations quickly came to the realization that above all else the first and most pressing requirement was for some method or system that removed individual protocol peculiarity from impacting the performance of itself or any other protocol. What was needed was some form of reference model.

Their next big moment of enlightenment came when they realised that it was all too much for just one individual or individual organisation to handle. In fact it was all too much for one protocol to handle and so the idea of a processing stack (suite of protocols) was born.

This alone was a big step forward but what good is a processing stack model if nobody knows who it works or how to use it? The solution was simple. Make sure everybody could access whatever they wanted. The result of this momentous inspiration was the creation of an OPEN standard for protocol design, architecture and implementation called the Open Systems Interconnect Reference Model (OSI model).

In this series we have had a look at most of the underlying background processes and process formation methodologies. We have also inspected protocol design and implementation, regulation, standards; both open and proprietary, standardisation, standardisation organisations, standardisation process and procedures, communications and networking protocols and introduced the OSI Reference Model.

All of these will be discussed in greater detail in the future but for now this will suffice. The next dozen or so articles; in the “About Protocols” series, will take look at individual communications and networking protocols on a one-by-one basis. I have decided to base the order in which I tackle this topic is by starting with the most commonly implemented protocols.

In order to make them easy to access and reference I will be calling them “About XXXXX” rather than giving each a sequential reference number. For instance an article about the Asynchronous Transfer Mode (ATM) protocol will be called “About Asynchronous Transfer Mode (ATM)” or “About ATM”.

I will also be compiling an index of the protocols covered which will also include the acronyms; if any, of the protocols that we discuss. I have decided to structure this index on an alphabetical ordering system where numbers; progressing from low to high as the list evolves, will come first. Then we will have the letters arranged in increasing alphabetical order.

Anyway this index will be named “About Protocols Index” for obvious reasons. I will also compiling a basic glossary that covers everything that we have or will be talking about. Guess what? I have decided to name this glossary the “About Protocols Glossary” also for obvious reasons.

Both the index and glossaries will be built on an “as-you-go” basis meaning that they will be regularly updated. I will also include a “what's new” section for your greater convenience.

So until we meet again enjoy.

We will now continue with a quick look at the primary types and “families” of protocols and some other basic terminology in preparation for a more detailed look into a range of “select” protocols.

Protocol Types

Basically protocols fall into either one of two types; open standard or proprietary standard.

Open Protocols

Open simply means that all of the nitty-gritty details, nuts and bolts are all laid out in a set of documents that is “openly” available to whoever may want to use them.

The biggest advantage of using an open protocol is that it ensures a greater degree of compatible interoperability between end-systems. It was for this very reason that the OSI Reference Model was developed in the first place.

Proprietary Protocols

Proprietary protocols; on the other hand, means that someone or something “owns” them. Think of them as being patented. The proprietor (owner) of a proprietary standard or protocol is under no obligation to disclose the details of “their” proprietary standards and proprietary protocols.

Furthermore; other parties are expressly prohibited from using a proprietary standard or protocol in any manner shape or form, without the prior, express consent of the proprietor (owner).

• Dead Bodies - Computer, network and communications technologies are littered with the dead or dying bodies of untold numbers of truly great protocols and technologies. In terms of their capabilities they outshone all of their peers and contemporaries. Yet they failed commercially. The reason was more often than not due to their proprietary nature.

For Example - Consider the two competing “hot swappable” device buses that have been with us for a few years now. I am talking about the open standard Universal Serial Bus (USB) and Apple® Computer's IEEE 1394 (FireWire™) standards.

• Open - USB being an open standard has meant that manufacturers wishing to make USB devices can refer to the open standards for the specifications that they need to comply with. If they do so and do make their product in compliance with these standards then their device will work in millions upon millions of USB enabled computer systems the world over.
• Proprietary - The scenario is totally different when it comes to Apple's® IEEE 1394 - FireWire™. Any manufacturer wishing to make a FireWire™ capable device must first approach Apple® computers and negotiate a royalties package before Apple® will even let them see the specifications data sheets.

With this royalty being very much like any other surcharge or tax the price of the products will undoubtedly be higher. This was and still is the case. FireWire™ devices are much dearer than their USB counterparts.

• Consumers have voted with their pocketbooks and so millions upon millions of USB devices are turned out every year and only a miniscule fraction of that in numbers of FireWire™ devices are produced annually.

Compound this with the economies of scale and mass production and it doesn't take a brave man to say that FireWire™ will never overtake USB end of story. Yes FireWire™ may hang around for a while yet but it is still doomed none-the-less.

Protocol Families (Stacks)

Protocols; particularly communications and networking protocols are not just one protocol rather they are a bunch of individual protocols that are interrelated. That is to say that each one can do its own job independently of the other protocols in the bunch. However; not much that we humans call worthwhile will ensue.

In order for this bunch of protocols to collectively take input, perform their own individual tasks and to collectively produce output that we humans can use or make use of the entire bunch of protocols needs to be orchestrated. That is they all need to do their jobs in a particular sequence.

Protocol Stack Processing

A protocol stack; or to be more accurate we should say protocol processing stack, is a layered set of protocols which work together to provide a set of network functions. [Source: RFC1392]

The really nice bit about using a protocol processing stack (layered model) is that each layer's output becomes the next layer's input. That is the output from one layer of a processing stack is the input of its immediately adjacent layers. It gets even better because the layers of a processing stack can function in both directions. In short:

• Transmission - When transmitting, each layer will take as input the complete output of its neighbour and treat that as a unit. It will then do its thing and wrap this unit into a new package which it passes onto to the next layer which does likewise in turn and so on the process goes.
• Reception - The opposite happens when the protocol stack is receiving. The protocol at each layer; unwraps the unit given to it by its neighbouring protocol, then passes the unwrapped unit to the next layer in the sequence, which does likewise and so on the process goes.

Open Standard Protocols

• Internet Protocol Suite (TCP/IP)
• Open Systems Interconnection (OSI)
• File Transfer Protocol (FTP)
• UPnP (Universal Plug and Play)
• iSCSI
• Network File System (protocol)

Proprietary Standard Protocols

• AppleTalk
• DECnet
• IPX/SPX (from Novell)
• Server Message Block (SMB) and CIFS
• Systems Network Architecture (SNA)
• Distributed Systems Architecture (DSA)
• Apple Filing Protocol (AFP)
• RSYNC
• Unison

In the next issue we will continue our discussion of protocols by examining some of their attributes standards and standards organisations along with the networking and communications aspects and considerations. Until then enjoy!

Protocol Implementation

• Hardware or Software - Protocols can be implemented in hardware, software or some combination of both.
• High-Level or Low-Level- They may also be high-level or low-level. High-Level and low-level are terms being used to refer to the protocol's relative position functionally on the seven layered OSI Reference Model.
  • OSI Low-Level Layers - The low-level layers are Layer One (the Physical Layer), Layer Two (the Data Link Layer) and Layer Three (the Network Layer).
  • OSI High-Level Layers - The high-level layers of the OSI Reference Model are: Layer Four (the Transport Layer), Layer Five (the Session Layer), Layer Six (the Presentation Layer) and Layer seven (the Application Layer).
• Open Systems Interconnect (OSI) Reference Model - The OSI Reference Model is a topic that I will cover in another article. So stay tuned.

Low-Level Protocol Implementations

At the lowest level the protocol will describe the low-level behaviour of a hardware connection including details of the machine-to-machine interfaces such as bit and byte order (the order in which bits and bytes are sent across a wire).

High-Level Protocol Implementations

With high-level implementations the protocol will be describing high-level exchanges such as those between allocation programs such as the way in which two programs transfer a file across the Internet.

Protocol Design Principles

In order to promote; greater consistency and more efficient build and design processes, in conjunction with a Rapid Application Design (RAD) philosophy the principles of systems engineering have been applied to network protocol design to achieve a set of common network protocol design principles.

These principles include: Effectiveness, Robustness, Reliability, and Resiliency.

Protocol Layering

Protocol layering facilitates protocol implementation by engineers and designers while satisfying requirements for routine usage by humans in human-machine systems.

• Napoleonic Tactics - The basic philosophy here; is one of, Divide and Conquer
• Sub-Division - A very intricate system is broken up into a number of smaller more easily defined and managed sub-units.

These sub-units will perform closely related sub-tasks while interacting with the other layers of the protocol in a limited number of precisely defined ways.

• Mix "N" Match - This makes for a “mix "n" match” approach to developing a network protocol processing stack possible.
• Benefits of the Layered Approach - I have discussed the benefits of using a layered approach to network protocol design in an earlier article entitled “Networking Protocols: Layering Benefits”
• More About the OSI Reference Model - Don't worry I will be getting to the Open Systems Interconnect (OSI) Reference Model in depth in another article soon.

Computing Protocols

A computing protocol is a set of rules, conventions and/or standards governing the communications between computers on a network as well as between various components within the machine.

These rules are designed to regulate various system and network characteristics, assets, services and support. They are heavily dependant upon the following factors:

1. The Physical Network Topologies Supported
   • Linear Bus, Tree, Star, Mesh, Hybrid etc
2. Transmission Media Supported
   • Supported Copper-Based Cable Types - STP, UTP, Coaxial etc
   • Support for Fiber-Optic Cable
   • Wireless Support
3. Hardware Supported
   • Network Interface Card (NIC) - Wired, Wireless
   • Chipset
   • Input/Output (I/O) - External expansion slots and adapter interfaces
   • Plug "N" Play - USB, IEEE 1394 (FireWire)
4. Data Transfer Parameters Supported - Data transfer speeds
5. Access Methods Supported
   • Password Power On - User must key-in the correct password before the BIOS will turn main system power on
   • Authentication - Local, Remote, Password Policies, Biometrics, Smart Cards etc
   • Wake-On-LAN (WOL)
   • Wake-On-Ring (WOR)
   • Real Time Clock (RTC) Power On - The machine will automatically startup at a pre-set specific time. Works very much like an alarm clock
   • Wireless Access Points (WAP)
   • Remote Access via ADSL, Telnet, PPP, PPTP, HTTP, HTTPS, FTP etc
6. Platform(s) Supported
   • Form Factor - AT, ATX, Server, Workstation, Desktop, Mobile, Laptop, Notebook, etc
   • CPU-Based - Intel, AMD, Multi-Core, Multi-Processor, 32-bit or 64-bit, Socket
   • Bus Specifications - AGP, ISA, EISA, PCI, PCI-Express, System Bus, USB
   • Memory Support - DRAM, SDRAM, DDR, Buffered, Non-Buffered
7. Operating System (OS) Supported - MS Windows, Mac OS, Linux, UNIX, OS2/Warp
8. Other Software Supported - Applications, Utilities, Tools, Widgets, Plug-in, Drivers etc

Some of the elements listed above may at first sight appear out of place. However; let me assure you, that this is not the case. For instance let us take a closer look at the humble Ethernet Network Interface Card (NIC).

Ethernet Network Interface Card (Ethernet NIC)

• Architecture - Ethernet is an architecture that describes everything at Layers one and two of the OSI Reference Model necessary for correct implementation including the types of cable and NIC that can be used
• When you buy a NIC; you bring it home, open the machine's case, plug the NIC into a spare expansion slot, and close the case. Now power up your computer. Your machine should boot.
• Once MS Windows® has loaded it (assuming you are running MS Windows®) should auto-detect the new hardware (the NIC that you just installed). A pop-up from the system tray will say something about Windows® has detected your new hardware and is installing the appropriate drivers.
• After a while another pop-up will appear informing you that your new hardware has been installed and is now ready for use
• All of the necessary protocol information required for the correct implementation and networking functionality of your new NIC is included with the firmware of your NIC
• The primary protocol that I am referring to here is the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) protocol which is the protocol used by Ethernet

Token Ring Network Interface Card (NIC)

On the other hand; suppose you wanted to connect a machine to a Token Ring network.

• You would go out and buy a Token Ring NIC, return home, plug it in, power up and away you go
• Just like Ethernet the Token Ring NIC has all the necessary Token Ring network protocols already built into the firmware of the NIC

Incompatibility

It is important to realise that; even though the Ethernet NIC and the Token Ring NIC can both plug into the same expansion slot on your machine's motherboard, they are both incompatible with one another.

In the next issues of about protocols we will be discussing protocol stacks, protocol standards, protocol standards organisations and converging communications. Until then enjoy!!

LAN Segmentation Using Transparent Bridges

Architecture Matters

Transparent bridges can be used with Ethernet networks. Other architectures require different types of bridges. For example Token Ring networks use a type of bridging technology called source-route bridging.

Reduced Outlay and Greater Return On Investment (ROI)

It's all about more bangs for the buck! Today a compact workgroup switch that supports transparent bridging such as those from D-Link, 3Com, Netgear and others can be obtained for well under $100.

Unmanaged Vs Managed

Switches that support transparent bridging can be of the managed or unmanaged varieties. The big difference; apart from the cost that is, is that unmanaged switches are a lot more user friendly than the managed variety.

Improved Network Performance

LAN segmentation using transparent bridges reduces the size of the network's collision domain(s) because it turns large collision domain(s) into a number of smaller collision domains with fewer machines per collision domain (LAN segment).

Fewer Collisions

Reducing the number and frequency of collisions improves the network's data transfer speed and efficiency

Reduced Competition

Improved data transfer rates and shorter wait states because fewer machines per segment means less competition for the finite available transmission bandwidth

More Effective Bandwidth Allocation

Improved Effective Available Network Bandwidth

Fewer nodes per segment means each node effectively gets a greater “share” of the available bandwidth.

Maximizing Returns

Since the available network bandwidth is a finite resource any measures that improve this aspect will have the greatest noticeable effect on the largest number of devices both individually and as a”collective”.

More Responsive Network from the Users Perspective

Improved Network Responsiveness

Segmentation of large collision domains into a number of smaller collision domains will result in users noticing an increase in the responsiveness of the network in terms of a reduction in the amount of time that their computer takes to gain access to the transmission media in order to transmit the job that the user has requested.

Faster Transmissions

Users will also see an overall improvement in the time taken to complete a data transmission or data reception task.

Shared Internet Services Improved

Internet searches; for instance, will be done in shorter periods of time than was the case prior to the segmentation.

Reduced Network Congestion

Transparent bridging can greatly reduce network congestion & bottlenecks. Only traffic that belongs on a segment will be placed onto that segment by a device implementing transparent bridging. How transparent bridging works its magic is a topic that will be discussed in a future article of the CCNA Summary Series.

Greatly Reduced Administrative Overheads

Reduced Installation Time

Because of the plug "n" play nature of transparent bridges administrators will spend far less time in installing this type of bridge or a switch.

Switches and Transparent Bridging

Most switches today support transparent bridging. The main difference between these switches and the traditional transparent bridge is in port density. Switches have massively higher port densities than traditional transparent bridges. It's all a matter of evolution.

Smaller Footprint

With higher port densities a modern switch that supports transparent bridging will occupy less physical space and so are ideal to use as workgroup out-of-the-closet scenarios.

Connection-Oriented Protocol Connection Services

The connection-oriented protocol services that we are about to discuss are the main factor that sets the connection-oriented protocol apart from the crowd.

While the exact mechanism that is used to establish a connection may vary from protocol to protocol the end result is always more or less the same. Connection established or connection failed. It is this end result that the user is aware of not the mechanics of what went on under the hood to get there.

For the purposes of this discussion we will be taking a functional view-point and so for the time being we will overlook the differences that various connection-oriented protocols may exhibit when establishing the connection. Quite simply it is the end result that we are interested in at this point in time.

Services Make the Connection

So it is that we will be focusing more on the commonality between various connection-oriented protocols and that begins with establishing the connection. The following services are common to all connection-oriented protocols and must take place in order for the connection to be established.

Physical End-To-End Connection Establishment

This must be implemented at both the hardware and software levels.

• First of all some form of transmission media needs to be made available by providing the necessary hardware
  • Now physically connect the devices (cabling etc)

In the case of wireless networking

• The physical transmission media is generally confined to being the connection between the Wireless Access Point (WAP) and other network hardware and infrastructure such as routers and switches
  • The connection between the WAP and the end node is wireless

Logical End-To-End Connectivity

Logical end-to-end connection(s) between the sending (local) host and the destination (remote) host are established. These can often be in the form of:

• Virtual Circuits (VC)
  • Permanent Virtual Circuits (PVC)

Connection-oriented protocols are responsible on an instance by instance basis for:

• The Establishment of the virtual end-to-end connection
  • Connection Identification of the virtual end-to-end connection
    • Ongoing Maintenance of the virtual end-to-end connection
    • Continued Support of the virtual end-to-end connection
    • Graceful Tear Down of the virtual end-to-end connection

Control Information is also passed between end-point protocols such as TCP.

• How, what, when, where, who, in what manner and what if? These are simple words but they have far reaching implications
  • These are all questions that all parties to a connection-oriented communications process need to reach agreement upon at this stage

End-To-End Data Transport Services

This component of a connection-oriented communication process is concerned with the actual transmission and reception of the data and cannot proceed until:

• The physical end-to-end connection has been established
  • The logical end-to-end connection has been established
    • All other prerequisite factors have been satisfied including such mechanisms as:
      • Authentication of the user as being “entitled” to access those features, data, services or assets currently being requested
      • Authentication of the requesting node as being “entitled” to access those features, data, services or assets currently being requested

Reliable Data Transfer

The terms “reliable networking” and “reliable data transfer” are generally accepted to mean that throughout the entire communication the following mechanisms will be used:

• Acknowledgments
  • Sequencing
    • Flow control

These are the mechanisms by which a connection-oriented protocol achieves complete and reliable (guaranteed) delivery of all of the data in the correct sequence thereby making true reassembly possible.

Reliable Data Transport Objectives

Through the use of a connection-oriented communications session between end systems the protocols involved ensure that the following will be achieved:

• Segments that have been successfully delivered are acknowledged; by the recipient, back to the sender immediately upon their reception.
  • All segments that are not acknowledged; by the receiver back to the sender, are assumed by the sender to have become lost or corrupted in transit and are automatically retransmitted.
    • Segments are sequenced back into their proper order upon arrival at their destination
    • A manageable data flow is maintained in order to avoid buffer overflows, congestion, and overloading all of which can result in data loss/corruption

Synchronisation Services

These are the mechanism by which the sender and the recipient agree upon to enable both to:

• Identify when the actual data transmission begins (i.e. identification of the first packet in the packet stream)
  • Identify when the transmission is complete (i.e. identification of the last packet in the packet stream)
    • Synchronisation of the rate at which the data is to be transmitted. This rate is agreed upon by both ends prior to commencement of the transmission and ensures that the transmitter does not transmit at a rate which the recipient cannot manage.

Much of the synchronisation services take place during the end to end link establishment phase. Other inputs include control information that both parties pass to each other.

Error Checking

• Uses the transport layer header checksum field to record the digest value
  • Uses a hashing algorithm; such as MD5, to produce the digest value that is to be placed in the checksum field

Data Segmentation and Reassembly

Large transmissions that exceed the maximum acceptable size of either the transmitter or the recipient can be successfully transmitted and received if the transmitter breaks them up into smaller subunits.

The maximum size of these subunits is agreed prior to data transmission and will therefore be one that both ends can successfully and reliably manage.

This process is what is known as segmentation and must be conducted in an orderly, repeatable and predictable manner if the receiving end is to have any chance of successfully reassembling the data stream back into its original format.

Connection-Oriented Protocols

The following are examples of connection-oriented protocols: TCP, ATM, Frame Relay, DCCP, Connection-Oriented Ethernet, Phone Call - user must dial the telephone and get an answer before transmitting data, TIPC, MPLS and SCTP (a new message-stream-oriented connection-oriented protocol that also provides for multiple streams multiplexed over a single connection as well as multi-homing support) TCP on the other hand is a byte-stream-oriented connection-oriented protocol.

Summary

In order to be classified as connection-oriented a protocol must exhibit the following characteristics and support the following services:

• The ability to establish, maintain and tear down a virtual circuit (e.g., a three-way handshake).
• Use Sequencing
• Use Acknowledgments
• Use Flow Control

Be seeing you in a future edition of The CCNA Summary Series

Guess what?

Today's topic: internal switching methods, is one that you must know. This is not optional; rather it is mandatory, and you can bet your bottom dollar that there will be questions on the CCNA exam that are directly related to and based upon your knowledge and understanding of these internal switching methods and concepts.

Network Foundations

Internal switching methods are the foundation upon which modern networks are based. This includes: businesses; large and small, home networks, government and educational institutions to name but a few. What's more they apply equally to both the managed (Cisco®, Netgear® etc.) and the unmanaged (D-Link®, 3Com® etc.) varieties of modern switches.

New Class of Networking Devices and Technologies

If you head on over to Cisco's® website and check out Cisco's switching and routing products roadmaps you will see that a new type (class/category) of network, networking and internetworking devices are now in full production and have already been implemented into production environment networks.

These new types of networking devices are based on what Cisco® likes to call a “switch/switching fabric”. There is little doubt that in the not too distant future we will be seeing the Cisco® switching fabric being incorporated into nearly all; if not all members of Cisco's hardware products range. It has already been integrated into their new Catalyst™ and Catalyst Express™ series of switches.

Internal Switching Methods

The three main methods of internal switching used in production environment switches today are; in order of increasing latency:

1. Cut-Through (Fast Forward)
   • When in Cut-Through mode the switch waits for the destination Media Access Control (MAC) Address (also referred to as the hardware address) to be received
   • It then looks up the destination MAC Address in its MAC filter table
   • Once the switch knows which port to forward the frame through it does so (even before the entire frame has arrived)
   • Cisco® sometimes calls this the Fast Forward method
2. Fragment Free (Modified Cut-Through)
   • Fragment Free is the default mode used by Cisco® Catalyst® 1900 series switches
   • It is also referred to as modified cut-through
   • When in Fragment Free mode the switch will check the first 64 bytes of a frame for fragmentation. The vast bulk of errors occur within the first 64 bytes.
   • Frame fragments known as runts are created as a result of collisions
   • If a runt is detected the switch will drop the frame
   • If all is well and there is no fragmentation the switch will then look up the destination MAC Address in its MAC filter table
   • Once the switch knows which port it should forward the frame through it does so
3. Store-and-Forward
   • When in Store-and-Forward mode the switch will store the incoming data frame in its internal buffer
   • Once the complete frame has been received and stored to buffer the switch will run a Cyclic Redundancy Check (CRC) against the frame
   • If the CRC passes the switch will then look up the destination MAC Address in its MAC filter table
   • Once the switch knows which port to forward the frame through it does so

Runts and Other Frame Corruption

Runts are the by-products of collisions. Simply by checking the frame for fragmentation before forwarding it greatly reduces the number of runts being propagated throughout the network.

Remember that the vast majority of errors occur in the first 64 bytes of the frame. By checking this part of a frame (the first 64 bytes) will allow the switch to detect and drop the majority of corrupted frames while doing as little work as possible. This is known as working “smarter”.

Reducing the number of runts and frames with other errors that are placed on the network's transmission media can improve network performance considerably. This is simply because we are not transporting runts or other corrupted frames that will be automatically rejected immediately the corruption is detected by the intended recipient.

The recipient bases this decision to drop the frame on the grounds that errors have occurred and/or these frames (the runts) are incomplete and so untrustworthy. Thus the intended recipient will automatically drop these frames.

So: if only, for reasons of efficiency and improved network bandwidth we may as well just drop them at the switch level because their eventual dropping is inevitable. In some instances this is the end of the line.

Once the device that requested the information in the first place: becomes aware that the frame never got through, it will issue are request for the remote device to retransmit that frame.

On the other hand if the remote device does not receive an acknowledgement from the requesting machine informing the remote machine that all parts of the conversation were satisfactorily received the remote machine will assume that something happened to the frame in transit.

And so it will then automatically retransmit any frames for which it has not received an acknowledgement of receipt for. These transmissions, retransmission requests and transmission control are the realm of the Transmission Control Protocol (TCP) if we are using the TCP/IP protocol stack.

I will be covering TCP/IP in another article. So until we meet again in a future edition of The CCNA Summary Series enjoy!!!

These are all concepts that we need to understand before we can get into the nitty-gritty of exactly what a specific protocol does, why it does it, why it does it the way that it does it, how it does it and when it does what it does. We also need to be able to distinguish the commonalities and differences that exist between different protocols. So let's get at it.

Routing

Routing is the process of moving data from one network to another network

Routing Protocols

In short routing protocols are the software that sends and receives routing information packets to and from other routers and in so doing allows the router to:

• Dynamically Advertise Routes
• Dynamically Learn Routes
• Determine Possible Routes
• Determine Route Availability
• Determine Route Efficiency
• Determine Best Route to Destination
• Determine Alternative Routes

Here are some of the routing protocols currently in use today:

• RIP - Routing Information Protocol
• RIP II - Routing Information Protocol II
• OSPF - Open Shortest Path First
• IS-IS - Intermediate System to Intermediate System
• IGRP - Interior Gateway Routing Protocol
• EIGRP - Enhanced Interior Gateway Routing Protocol (Cisco proprietary protocol)
• BGP - Border Gateway Protocol

All you need to remember is that routing protocols convey routing information such as routing tables, network IDs, hop counts, administrative distance/cost, other metrics and autonomous numbers to neighbouring routers.

To illustrate this here is a simple version of what routing protocols get up to:

Router1: “Hey! Neighbour here is something really good it's my routing table. Check it out and see if there is anything in it that you don't know already.”

Router2: “Well thanks a lot. Here is mine. Do likewise.”

Routed (Routable) Protocols

A routed protocol is routable meaning that it can be routed by a router. This means that it can be forwarded from one router to another.

Routed protocols contain the data elements; such as IP Addresses, that are required in order for a packet to be sent outside of its host network or network segment.

IP (Internet Protocol) and IPX (Internet Packet Exchange) are examples of routed protocols.

Non-Routable Protocols

Non-routable protocols cannot survive being routed. In short non-routable protocols have a very narrow world view in that they assume that every computer that they will ever need to communicate with exists on the same network segment as them.

Today we find that those protocols that are not multi-segment aware are disappearing from use. The following are examples of non-routable protocols:

• NetBEUI
• DLC
• LAT
• DRP
• MOP

Interior Gateway Protocols (IGP)

Interior Gateway Protocols are used to communicate routing information between routers within an autonomous system. Because they transport (communicate) routing information they are routing protocols and not routed protocols as many people mistakenly believe.

Conclusion

Today the world is very Internet centric and so we find that those elements, protocols, systems etc. that can't get along with the Internet are doomed to fade rather rapidly into oblivion and non-routable protocols are among the first to go.

Well it's now time to go. So until we meet again in a future edition of The CCNA Summary Series enjoy!

The Hierarchal Approach to Network Protocol Development

The hierarchal or layered approach to networking produces what is known as a layered architecture. This is in contrast to the “flat” or “horizontal” approach. The benefits to layering networking protocol specifications are many including:

Interoperability - Layering promotes greater interoperability between devices from different manufacturers and even between different generations of the same type of device from the same manufacturer.

Greater Compatibility - One of the greatest of all of the benefits of using a hierarchal or layered approach to networking and communications protocols is the greater compatibility between devices, systems and networks that this delivers.

Better Flexibility - Layering and the greater compatibility that it delivers goes a long way to improving the flexibility; particularly in terms of options and choices, that network engineers and administrators alike crave so much.

Flexibility and Peace of Mind - Peace of mind in knowing that if worst comes to worst and a key core network device; suddenly and without prior warning decides to give up the ghost, you can rest assured that a replacement or temporary stand-by can be readily put to work with the highest degree of confidence that it will do the job.

Even though it may not be up to doing the job at the same speed it will still do it; at least, until a better, more permanent solution can be implemented. This is a state of affairs that is much more acceptable than for a lengthy cessation of network services or assets unavailability to occur. 80% is oh so much more pleasing than 0%.

Increased Life Expectancy - Increased product working life expectancies as backwards compatibility is made considerably easier. Devices from different technology generations can co-exist thus the older units do not get discarded immediately newer technologies are adopted.

Scalability - Experience has shown that a layered or hierarchal approach to networking protocol design and implementation scales better than the horizontal approach.

Mobility - Greater mobility is more readily delivered whenever we adopt the layered and segmented strategies into our architectural design

Value Added Features - It is far easier to incorporate and implement value added features into products or services when the entire system has been built on the use of a layered philosophy.

Cost Effective Quality - The layered approach has proven time and time again to be the most economical way of developing and implementing any system(s) be they small, simple, large or complex makes no difference.

This ease of development and implementation translates to greater efficiency and effectiveness which in turn translates into greater economic rationalisation and cheaper products while not compromising quality.

Modularity - I am sure that you have come across plug-ins and add-ons. These are common and classical examples of the benefits to be derived from the use of a hierarchal (layered) approach to design.

Innate Plasticity - Layering allows for innate plasticity to be built into devices at all levels and stages from the get-go, to implementation, on through optimisation and upgrade cycles throughout a component's entire useful working lifecycle thereafter.

The Graduated, Blended Approach to Migration - Compatibility enables technologies to co-exist side-by-side which results in quicker uptake of newer technologies as the older asset investments can still continue to be productive. Thus migration to newer technologies and standards can be undertaken in stages or phases over a period of time.

This is what is known as the graduated blended approach; which is the opposite of the sudden adoption approach.

Standardization and Certification - The layered approach to networking protocol specifications facilitates a more streamlined and simplified standardisation and certification process; particularly from an “industry” point of view. This is due to the clearer and more distinct definition and demarcation of what functions occur at each layer when the layered approach is taken.

Task Segmentation - Breaking a large complex system into smaller more manageable subcomponents allows for easier development and implementation of new technologies; as well as facilitating human comprehension of what may be very diverse and complex systems.

Portability - Layered networking protocols are much easier to port from one system or architecture to another.

Compartmentalisation of Functionality - The compartmentalisation or layering of processes, procedures and communications functions gives developers the freedom to concentrate on a specific layer or specific functions within that layer's realm of responsibility without the need for great concern or modification of any other layer.

Changes within one layer can be considered to be in self-contained isolation; functionally speaking, from the other layers. Modifications at one layer will not break or compound the other layers.

Side-Kicks - The development of “Helper” protocols or side-kicks is much easier when a layered approach to networking protocols is embraced. This is especially so when it comes to the development of “helper” protocols that are developed more or less as after-thoughts because the need arose.

Reduced Debugging Time - The time spent debugging can be greatly reduced as a direct result of taking the layered approach to developing network protocols because debugging is made easier and faster when using the layered approach as opposed to not using it.

Promotion of Multi-Vendor Development - Layering allows for a more precise identification and delineation of task, process and methodology. This permits a clearer definition of what needs to be done, where it needs to be done, when it needs to be done, how it needs to be done and what or who will do it.

It is these factors that promote multi-vendor development through the standardisation of networking components at both the hardware and software levels because of the clear and precise delineation of responsibilities that layering brings to the developers' table.

Easier Binding Implementation - The principle of binding is far easier to implement in layered, tiered, and hierarchal systems. Humans also tend to understand this form easier than the flat model.

Enhanced Troubleshooting and Fault Identification - Troubleshooting and fault identification are made considerably easier thus resolution times are greatly reduced. Layering allows for examination in isolation of subcomponents as well as the whole.

Enhanced Communications Flow and Support - Adopting the layered approach allows for improved flow and support for communication between diverse systems, networks, hardware, software, and protocols.

Support for Disparate Hosts - Communications between disparate hosts is supported more or less seamlessly thus Unix, PC, MAC & Linux to name but a few can freely interchange data.

Reduction of the Domino Effect - Another very important advantage of a layered protocol system is that it helps to prevent changes in one layer from affecting other layers. This helps to expedite technology development.

Rapid Application Development (RAD) - Work loads can be evenly distributed which means that multiple activities can be conducted in parallel thereby reducing the time taken to develop, debug, optimize and package new technologies ready for production implementation.

Conclusion

As you see the benefits of adopting the hierarchal approach to networking protocols are many. The reason that carries the most weight in any given situation will be situation dependent.

Well it's now time to go. So until we meet again in a future edition of The CCNA Summary Series enjoy!

In no particular order, the following resources are arguably the most useful in preparation to take the CCNA exam:

CCNA Exam topics list

This list should be the starting point for any serious candidate. It lists all the relevant topics that will possibly be tested on the exam. These guidelines are extremely useful during one's preparation. A few months ago when the new CCNA exam was rolled out (640-802) the list was updated to provide slightly more detail in the objectives - take advantage of that and KNOW all those topic areas without exception. Neglect that and the probability of passing begins to drop exponentially. The list can be found here, at the Cisco website.

Network Simulator or the Real Deal

The exam has simulation questions. Expect a couple of questions that require you to type in command line interface (CLI) directives to perform a task e.g. configure EIGRP on a set of routers. For practice you need to get a simulator such as Boson's NetSim for CCNA or RouterSim's CCNA NetVisualizer. Those will probably cost you some change, but are worth it if you get to use them. Of course the Real Deal is having an actual router or switch then the experience gets as real as can be. Some have scored great deals on CCNA racks from EBay or Amazon. There's a free router simulator, Dynamips that supports the Cisco 7200, 3600 series, 3700 series and 2600 series. There is a learning curve to this though but once you get the hang of it, you'll realize how useful and cost-effective (free!) it is.

CCNA Study Guide by Todd Lamlle (Sybex)

Many people have found that this book is easier to read than many other tech books because of the casual manner in which it is written. I've read an earlier edition of this book and found this to be so. The content covers well the objectives for the exam. Practice tests are also included, so take advantage of them; the same concept tested may show up in the actual test. Amazon.com is a great place to get title this from.

CCNA Official Exam Certification Library by Wendell Odom (Cisco Press)

Wendell Odom has a great deal of experience in the networking industry and it shows in the level of depth in technical content his books have. This book is no exception. In fact I consider most of his books not just written for the exam but for the work place too (indeed, i've kept most of mine). Use the simulation tests offered to hone those configuration skills. Again, Amazon.com is a good place to check out for this book.

CCNA Forums

Go register at the CCNA Prep Center; there's a ton or resources to peruse over. Also head over to Group Study; there are plenty of people in the same boat as you either taking the exam or technically competent to answer your questions. Be certain to read the forum guidelines first before you post, else you may suffer the wrath of other forum members or get banned by the webmaster altogether. There are a lot of other forums out there, find your fit.

Extra mile:

Still have that nudging question or missing piece in the puzzle that just isn't adequately covered in the study guide? Or your thirst for deeper technical knowledge surpasses what the book has to offer? Well, you're in luck because Cisco Documentation at the Cisco.com site has all that and more. It's a treasure trove. This is the same (and only allowed) documentation set used when taking the CCIE lab. Initially, navigation through the site may take a little getting used to.

Last Word:

Need motivation to carry you through your studying? Register for the exam! Some of us work better with deadlines set. Register early, weeks in advance. Once you pay, you'll get motivated to study.