On 17 January I found the time to attend a T216 (OU website) day school that was hosted at London Metropolitan university. T216 is a module that is all about Cisco networking and, in some respects, it’s a little bit different to other OU modules, but it’s different in a good way.
Students who study T216 can gain credits towards their degrees whilst at the same time taking a set of vendor exams that allows them to gain a widely recognised industrial qualification. You study one module, and have the potential to gain two different outcomes.
Labs
Another way that T216 differs to other OU modules is that students are required to attend a number of compulsory lab sessions. These lab sessions are opportunities for students to get their hands on real Cisco equipment: the same type of equipment that powers much of the internet.
I have to confess that I’m not a network engineer, but have been a student of networking in the past. I first studied it as an undergraduate (when things were very different) and then briefly went down the Microsoft systems engineer certification route, but I’ve always known that the official Cisco certifications are a whole lot more demanding.
When I worked in industry, I once made a case to develop a product that could be used to help to teach the fundamentals of computer networking, using a set of tiny PC-like computers. When I was heading to this event, I remembered these old ideas and I had two questions in my mind. The first was: what is the Cisco way of teaching networking and, secondly, what might happen in a Cisco lab.
The teaching bit
I met my colleague in the foyer of the university and I was quickly taken to teaching lab where a lecture was taking place. I found a seat at one of the empty workstations and started to listen, hoping I would understand something.
‘How do switches learn mac addresses?’ our instructor asked. The class was still pretty quiet: the students hadn’t yet warmed up yet. I knew what a ‘mac’ address was: it’s a unique id that is used to identify a network node. You can have them on either Ethernet cards and are used by wireless devices (as far as I know), but in this context, the lecturer was only talking about wired networks. I also knew what a switch was too: it’s a device that decides where different signals (or frames) should be transmitted to. Switches have ‘ports’, which are linked to physical cables (if I’ve got this right!)
The answer was: the switch populates the CAM tables, and if it doesn’t know where to send something, the switch transmits everything on every port by doing a broadcast, so it gets to behave a bit like a ‘hub’. Broadcasting also happens if a CAM table gets full, and this is something that hackers can exploit. To deal with this, there’s also something called port security. To make things even more complicated, there are different types of port security too.
Within fifteen minutes, my head was exploding with in-depth technical detail. I was also reminded about the different layers of the ISO 7-layer networking model (‘a switch is a layer 2 device whereas a hub is a layer 1 device’): I was being reminded about parts of my undergraduate studies.
During the teaching part of the day, we were introduced to the concept of a VLAN and its benefits, and the concept of ‘VLAN trunks’. I also made a note of the glorious phrase ‘a router on a stick’.
On the subject of packet routing and routers (which was a ‘level 3’ device, apparently), other concepts were introduced, such as a ‘routing table’ and different types of dynamic routing protocols, which had names like: EIGRP (enhanced interior gateway routing protocol), OSPF (open shortest path first) and RIP (routing information protocol). These protocols were different in terms of the extent to which they were connected to vendors, and the way they approached ‘cost’. Cost, in networking terms (it seemed) could be considered in terms of networking distance, or state (or quality?) of a link.
I appreciate all this sounds pretty hard-core technical, but what does all this mean? Routing protocols (as far as I understand) are important, since they convey the status of the network to the other magic devices that keep the internet working. If there is a bit of the internet that stops working, it’s important that other devices know about it, so they can channel packets around the bits of it that are having problems.
During this part of the class, I had another flashback to my undergrad years, where I studied different types of computer algorithms. One of those algorithms, called Dijkstra’s Algorithm, was all about finding the quickest path through a network. His algorithm can be used to help your satnav to find the shortest route to a destination, or to find your way around the London Underground Tube map. It can also be used to direct internet traffic. If you’re interested in this kind of stuff, I recommend you have a quick look at M269 Algorithms, Data Structures and Computability. In computing (as with networks) everything is connected (in one way or another!)
Other ‘teaching bits’ included information about something called an ‘access control list’ (which allows for network filtering), DHCP (an abbreviation for Dynamic Host Configuration Protocol) and NAT (network address translation). This connected to the point that there are two different internet standards: IPv4 and IPv6. Please don’t ask me about IPv6, because I don’t know too much about it, but what I do know is that NAT is like a ‘fix’ to get around the problem that there are more internet enabled devices in the world than there are IPv4 internet addresses. There’s also something called PAD, or port-address translation (but I don’t know too much about).
In essence, we were being taught about the nuts and bolts of the internet and how it worked. It’s all very well hearing theory, but nothing beats actually playing with physical hardware. That’s when the lab session comes in.
The playing bit
We had a task to do: we had to connect three different routers together, configure them, and get them talking to each other. The routers (along with ancillary hardware, such as racks of switches and cabling) were situated in different parts of the lab. After our tutors described our task, we were all encouraged to go up to the racks to try to figure out what was what: we had an opportunity to eyeball and touch real physical Cisco hardware.
I followed the cables between the different devices and asked some questions about the various interfaces. I could see how it was set up. I was also informed that the hardware was set up in ‘a raw state’ that meant that we had to send commands to them, to try to get them speaking to each other.
I sat down at a computer workstation. I then figured out that a workstation had a link to one (or more) of the routers. Each workstation was pretending to be a really old ‘dumb terminal’, which was the kind of interface you needed to use to talk to the router.
Our tutors gave us a handout, and a glossary of commands, and it was left up to us to figure out how to get the routers working together. Thankfully, I was paired up with someone who knew how to issue the device with instructions. Between us, we figured out how to send a ‘reset’ command and give it a name.
After quite a bit of head scratching, asking questions and mild cursing, I suddenly understood what was going on. There were three routers. Each router was connected to a separate terminal (or workstation) where we had to issue different sets of commands. I was trying to be clever and think that you could do everything from a single computer – but, there were clear pedagogic reasons why it was designed this way: to keep it simple, so we could more easily figure out what was going on. (Or, at least, this was my hypothesis!)
Half an hour later, we had all the routers (pretty much) talking to each other, which was our first assignment (which was what everyone would have done at the end of the previous day school). Other groups in the lab session (who were more familiar with the commands that they needed to issue) were storming ahead, spotting mistakes in the script, and forging a path to the next assignment.
Since I was there just to observe and to learn, and I was becoming increasingly confused (and I had another appointment), I decided to call it a day.
Final notes
The teaching bit was great, and the lab bit was good fun, but there was a huge amount of detail to take in over a very short period of time. I managed to understand some stuff, but quite a lot of the detail passed me by – especially when it came to working with the actual hardware. This, of course, relates to the importance of the labs. Nothing really beats an opportunity to work with real kit (and also to work with other students who are going through the same learning process that you are).
Although I left early, I did feel that I would be able to master a lot of what was being covered during the day school. This made me wonder: I wonder if the other day schools might be different. Also, since I found the stuff so geekily interesting, I had another question, which was: could I find the time to officially study this module?
At the moment, time, is a challenge. I’m currently embroiled in writing up three different teaching and learning research projects. Once I get these out of the way (and another couple of side projects I’m working on), I’m sorely tempted to give T216 a go.