Posts Tagged ‘Networking’

How I nearly failed (part of) the CCNA again

June 17, 2013

A Little Bit of History

CCNA for me has been a long journey. I first saw the cert 8 or 9 years ago, and I’ve always fancied giving it a go, but never had the opportunity until my current role. I’ve managed to fail the combined CCNA exam twice so far, at my employers expense, and took a break to get some of the Microsoft Windows Server 2012 certs under my belt to keep us in line with Partnership levels. Now I’m back to the CCNA in earnest. (more…)

CCNA – 1 – Purpose and Function

March 27, 2012

Introduction

This is the first post in a series as I work through the CCNA syllabus. The introduction to the series can be found here.

I will be pretty much following the CCNA Composite Exam Blueprint point for point. One post per bullet point. I’m using Version 11 (640-802).

Purpose and Function

The bullet reads: Describe the Purpose and Function of Various network devices

Various isn’t too well defined, but at least for this purpose we know that we are dealing with devices found in a small office or branch office networks. So, what devices do we have?

First we have the networking devices:
* Hubs
* Switches
* Routers
* Access Points
* Hardware firewall devices

These are the devices that make up the network itself.

Client Devices:
* Desktop and laptop computers
* Tablets
* Smart Phones

These are the devices that the network exists for, the devices that access the network and utilise it.

Finally we have service devices:
* Printers
* Servers
* Storage units

These are the focus of the network, the devices the users are trying to access.

These are very arbitrary groups, and I have picked them because that is how I think of them. Printers for example work very much more like a client in reverse, receiving data rather than requesting or sending it. In a SAN, servers act as client devices for the storage.

Broadly speaking though, the client devices connect either using wired, or wireless (more on both later) connections to the network devices. The network devices provide a transport system, usually with security in mind, for the clients to the server devices such that the clients can make a request, and the server devices can fulfil the request.

A small example of this? Why not. A user sat at a computer would like to be sure the computer has the correct time. The computer is connected to a switch, which is connected to a server which is running NTPd. The user sends a request, picked up by the switch and forwarded to the server. The server sends back the correct time, using the reverse route.

Now, lets take those network devices in a little more detail.

First we have the hub. Don’t see many of these, and I’ve never seen one in production use! A good place to start then. A hub is basically a repeater, like a parrot, everything it hears, it repeats. Any data in to any port is immediately sent out of all other ports. This means that each port on a hub is within the same segment, and collisions are more and more likely with more ports.

Hub, 1 segment, 1 collision domain.

Next the switch. A switch starts off like a hub, but for every request it receives, it remembers the MAC address of the requester, and the port the request came in on. That way, once a request destined for that MAC is seen, it only needs to be sent out of one port, not many.

Switch, 1 segment, many collision domains.

Routers work at the level above switches, effectively moving packets based on IP address, rather than MAC address. This makes each port on a router a separate segment, and by virtue of that a separate collision domain.

Router, many segments, many collision domains.

Access points are effectively hubs for wireless devices. Using the shared medium of the same “channel” of the spectrum each client device shares the bandwidth of the access point.

AP 1 segment, 1 collision domain.

I’ve rambled a bit there, and I haven’t touched on how full duplex cabling effects the collision domain with modern switches, or fun things like VTP and how to avoid switching loops.Fortunately, they come later in the blueprint.

Gentoo, WGET, and IPv6

February 15, 2011

Well, I may as well make use of my IPv6 Tunnel, but how to get Gentoo to prefer IPv6 where it exists?

My /etc/make.conf has lines for wget, but apparently they are out of date and have invalid escaping, leading to an error:

ValueError: No escaped character

Looking at a newer make.conf.example (hidden away in /usr/share/portage/config/make.conf.example) I see that the way file paths are written has changed. Merging the command to prefer IPv6 and the new format gives:

FETCHCOMMAND=”/usr/bin/wget –prefer-family=IPv6 -t 5 –passive-ftp -O \”\${DISTDIR}/\${FILE}\” \”\${URI}\””
RESUMECOMMAND=”/usr/bin/wget -c –prefer-family=IPv6 -t 5 –passive-ftp -O \”\${DISTDIR}/\${FILE}\” \”\${URI}\””

Which works like a charm….