Connecting to Equipment

One thing to note is that we wouldn't necessarily have to get onto the equipment and program it in order to use it. Most switches nowadays come with some default setup on it, so you could just plug it in and start working with it. But if we do want to program it, to give it some additional functionality, then we're going to have to get into that piece of equipment and start doing some configuration of it.

So to connect to it, we have some ways to virtually connect to it, like through vty lines. But the problem with that is you have to have certain things set up just in order to be able to virtually connect to it. So initially what we need to do is we need to set it up through the console. We need to physically plug into that piece of equipment, program it, and then from then on out, once we do some initial programming of it, then we can remote into it from anywhere — anywhere that we set it up to remote in from, at least — and do configuring of that piece of equipment.

Connection types

Some of the connection types to this equipment: the console, plugging into the console, and so that's the one we're going to be talking about right now.

There is an auxiliary port, so if you needed to dial up a modem in order to connect into the equipment and configure the equipment, that would give you something that's completely out of band, some other system to get into that equipment and configure it. So if you lose contact with that equipment somehow, you have another method of getting into it, which is why you'd use something like a modem to dial up and connect into it.

Then you have your virtual terminal, or your vty lines, so whether you set it up for telnet or SSH. And then there's also the web interface, which once again Cisco doesn't really promote or teach, getting into the web interface, although it can sometimes make things easier, and there are other brands that promote that much more than Cisco. So most engineers, I'd say, use the console to get in and program Cisco equipment.

Terminal emulation software

Let's get into terminal emulation software, because that's what we're going to use in order to console into this device. Now where does that come from? Why is it emulation, terminal emulation? That's because it's emulating a terminal. What is a terminal? Let's dial back into history and take a look.

In our history we had these big huge processing devices. They were big mainframes, and you would share that compute process with everyone else, and so you just had one big huge processor. You wouldn't have these individual laptops or desktops or anything that would sit on your desktop that would process it. No, it all went back to a big mainframe. And then what you would have to do all your processes and stuff on is you would have a screen and a keyboard, and that would be your terminal, this screen slash keyboard combination.

What you would do is you would press an A or some letter on your keyboard, and that A would get sent to the mainframe to be processed. That processor then would say, okay, what am I supposed to do with the A, and figure out what it's supposed to do with that A. If it was to display it on your screen, then that information would be projected back onto the screen and you would get an A up on your screen. So it would do this if I was typing out Andrew: every letter would be going to the mainframe, get processed, and be sent back to my screen. Perhaps there are some letters that maybe are part of a menu or something, and you press A and then it would bring up the next setup menu, or execute whatever it is that it's supposed to execute.

So that's the terminal, that's the way the terminal slash mainframe systems used to work.

Now we have software that emulates that. We've got this equipment that is still used to that same setup, and so now we need to have some sort of software that emulates being a terminal to connect into that device. Some examples of that would be Tera Term, HyperTerminal, PuTTY, SecureCRT. We're actually going to be using PuTTY through this course, so I've got an example of this.

This is our PuTTY setup right here, and we're going to get more in depth into what our settings are, but this is our terminal emulation software that's going to emulate: when we press an A, it's going to send it to the equipment, and that equipment's going to process it, and then it's going to probably display something back or execute.

Making the physical connection

So now we have our machine that has some sort of terminal emulation software installed on it, and we are making a connection to a switch. That's going to create some sort of connection that we can console into and type things out and configure it.

So we physically need to make that connection between our computer and that end device. It's an RJ45 connector that connects into a lot of these consoles, or some of them will actually use USB console connectors, but a lot of these devices, you still use the RJ45 connector to go into it, and it uses what's called a rollover cable.

A rollover cable, these are these blue cables usually — at least the Cisco ones are quite often these really light blue. It's got an RJ45 on one end, and then it's got an RS-232 connector on the other end. It's a DB9 pin here.

What a rollover cable does

So we've got this connector, and we call these rollover cables. That's a little bit misleading. I'm going to explain what a rollover cable is. When you actually look at the pinout, it doesn't quite work out this way in reality, but the concept of the rollover cable is what I'm about to explain here.

Let's say you have two pieces of equipment that need to talk to each other, they need to communicate. There's going to be some sort of receiving and some sort of transmitting that's going to happen. What I'm using as an example is, this is one piece of equipment on this side and this is another piece of equipment on this side. We plug a cable in that connects the two, and so we've got these cable connections that go through here that are connecting this in.

Now the problem with this is that if you just have a straight through cable, this device right here is trying to receive on pin three, whereas this device is trying to receive also on pin three. In other words, they are both listening to the same line. Also, we see that on pin six here this device is trying to transmit, and on this pin right here this is trying to transmit. So this is like me trying to talk to somebody else through their mouth, or listen to them through their ears. It doesn't really work.

So somehow we need to have our transmit being sent to the receive on each of the ends. There are several ways to do this, and Ethernet does it one way with something like a crossover cable.

So what a rollover cable does is it just takes the first pin and goes to pin eight, and it takes the second pin and goes to pin seven, and the third one and to six, and then you can kind of see where this is going. We just roll everything over, so all of these are going to go to the reverse side. Just think of it as all of them are getting rolled over in that cable, or the ends are transposed.

So then what happens with that is that transmit is sending to the receive that way, and this transmit is sending to that receive in that direction. So now we have communication. So that is a rollover cable. Like I say, it executes a little differently when you're talking about these RS-232 connectors, but in essence that's what a rollover cable has historically done, and so that's why we call it a rollover cable.

Signaling

Now let's talk about signaling. I'm sending ones and zeros across this copper cable. Now the thing is that equipment over there listens at a certain rate, and I am speaking at a certain rate, and if those two rates are not the same, then we are not going to communicate.

What I mean by that is, here's my signaling right here. So this would represent a zero, this would be a one, zero, zero, zero, one, one, one, zero, one. So that is my signaling that's going across that wire. I'm turning the power on and off through that wire to send that signaling.

Now the thing with this is, let's just get rid of these first two and last two bits and just use the middle section here. If I didn't have these blue lines, that's what talked about the signaling — these blue lines tell me right here where the bits lie. That's just something that I put on my model, but a machine doesn't have those blue lines on it.

So what it could actually misconstrue this as, these middle bits, this could be represented as a zero and this could be represented as a one. So some equipment could interpret this as being two bits: it's received two bits of data, it's received a zero and a one, not six bits but two bits, rather than receiving a zero, zero, zero, one, one, one. Some equipment, if it's speaking a different language or a slower language, then it's going to see this as a zero and a one. So there's a problem with that, obviously.

So what we need to do is we need to have a setting that says, no, this is the pace that we're going to talk. And the pace that you're going to talk is the distance between these two lines right here. So that is signaling, and there are certain rules with the signaling that we're going to have to learn about as we talk back and forth.

The settings

So what are the settings that we're going to need to be looking at? First of all, we have to set what is called the baud. The baud is the binary assembly unassembly data. So what does that mean? It's just the timing of all this. It's essentially saying what is the timing of the communication, or the speed in which we're going to be communicating at.

It is a little different than what we call bits per second. Initially the bits per second lined up with the baud rate, we'd send up a bit for every baud that we had, but that's no longer the case, because we're able to pack a little more data into it. So I just consider this is just the speed in which we talk. Just consider it that for now, we won't get too in depth into the technical side of that. But what we want to do when we connect to Cisco equipment is we want a baud rate of 9600.

And then we have the data. The data is the piece of this that we're sending over. That is going to be the data side of it, so the bulk of it. If we're sending an A, it would be that A that we're sending over.

Then we have the parity. This is if we want any kind of checks and balances with this, a little double check of, hey, is this information accurate when it gets over there. The default that we have set there is none, so we don't have a parity bit set.

And then there is a stop bit. In here we actually have a start bit and we have a stop bit, and this right here just says whether we use a stop bit or not, and we do set that. So 9600 8 none 1, 9600 8-N-1. That's what we used to connect to a lot of these devices.

Nowadays you'll get familiar with this if you're using the console cable a lot. Nowadays a lot of our terminal emulation software is actually set to this by default, so it may not be that we really see it much at all in our software emulation. So in our terminal emulation software what we're actually going to do is select that 9600 8 none 1. It's abbreviated often as 8-N-1, so you'll see it in a few different forms, but like I say, by default it's already really set up on your device.

Once we select that we want to connect via the serial cable, we can go down to the serial settings and actually see where these settings play out. On this we see that this is set to a baud rate of 9600, that it has eight data bits, and it has a stop bit, there is no parity, and the flow control is XON/XOFF.

So these are the settings, and it's interesting, if you get these settings wrong in here, then what you'll see up on your screen is just kind of some garbled, looks like something from the Matrix, that is just incomprehensible of what it's displaying on your screen.