Welcome to our CCDA lab. While we were discussing network design methodologies, we mentioned that one of the important activities to be carried out during a design is network audit. So even though network audit is easier done with automated tools, there are some commands on the Cisco IOS devices that can give us information about a network and the devices running in that particular network.

In this lab, we’ll be looking at such commands. For this CCDA lab, we’ll be using GNS3 and Packet Tracer. Since CCDA is about design, the labs are not so much about configuration. Instead, we’ll be looking at different scenarios that touch on different parts of network design.

Here, we have a very simple lab. We just have two routers connected together. And now, we’re going to look at a few commands. I will open the console of R1. The first thing that you want to do, or that you may want to do, is show version. Show version will show you two things, or a couple of things actually. It will show you the iOS version that is running on that particular device. It will also show you the type of hardware that is on it. It will show you the amount of interfaces and things like that.

This is very useful for checking end-of-life. It’s very useful for inventory, and also checking end-of-life startups. For example, you could go to the Cisco site and check whether this version 12.4(25d) is end-of-life and maybe there’s a new version that you can upgrade to. The hardware is listed here. This is the Cisco 3745 and then we can see the amount of vital memory. We can see how many interfaces are on this device. So, right now, we have two FastEthernet interfaces. And we can see a couple of other information about NVRAM and things like that. This is very important, like I said, for inventory purposes.

Another command that you’ll want to use, of course, is your show run, show running-config. Show running-config will show you the configuration that is on the device. In this case, we have a very simple configuration. We have hostname, the hostname is set. We have, if I scroll up, I think I have debugging, yeah. I’m logging to the buffer. The buffer is like the internal memory of this particular device, and this is the size that we specified for the logs. Once the logs have gone past this size, it just starts overriding the old logs.

I also have some IP, like interface configuration, IP addresses and stuff like that. Keep in mind this particular command, ip flow ingress. We use for NetFlow. I might be able to see a particular command that would be useful for NetFlow. And then we also have EIGRP. We have EIGRP running. And I think that’s about it. I have also configured CIS log, even though I don’t have any host on this particular address. Alright, good.

Another thing, of course, is to check your startup configuration. The only time your startup configuration and running configuration will be different is if you’ve made changes to your running configuration and you’ve not saved it. In my case, it’s the same thing because I haven’t made any change. Let’s do something actually. Let’s look at our vty line. Right now it just says login. I’m going to change it. Line vty 0 4, let’s just set a password. I’ll set a password, say, cisco. So, if I check my running configuration, I can see the password that I set. But since I haven’t saved, if I check my startup configuration, it’s not there. So, that’s the only time there will be a difference. Okay, good.

Another very useful command is the show interfaces. It will give you the hardware information and also some IP address configuration and things like that. In this case, we can see that our FastEthernet 0/0 is up up. Up and line protocol is up. If there’s any down here, then you know that there’s a problem. We can see the particular IP address that we have. And one thing you want to pay attention to, here, are these figures here. Under your input and your output. You want to check if you have any errors or if there are any overruns or things like that. There are times when you’re going to have errors, that’s standard. But if you have too much of them, then maybe there’s a problem happening. Check your input and your output errors and stuff like that.

Another useful command is show cdp neighbors. Show cdp neighbors is very important because you may not know all the devices that are connected to your particular device. In this case, we have R2 is connected. Keep in mind, cdp is not always enabled. There are cases where people turn it off for security reasons. But cdp can give you some very pretty good information. Look at this, we have R2. In fact, if I use the detail, I can see more information about R2. So, I know the software version that is running on R2, I know what platform it is, I know the IP address, and things like that. Yes, it’s really cool. The amount of information you can get from cdp.

From here, I can now go to maybe R2, since I know that R2 is also on this network. You remember that it’s not every time that you have a network diagram like this. There are times you only know maybe just one device, and you’re trying to find all the other devices on the network. cdp would be very useful in that case.

Something is show logging. I will show you all the things that we have currently. We’re doing CIS log, we’re doing console, we’re doing monitor. Monitor is when you come in through Telnet and SSH. Buffer is the one, like I said, that is stores in the internal memory of the router. If I go down, I can see a couple of log messages that I’ve stored in the buffer. For your buffer, you may not want to use debugging. You may not want to use severity level 7. Maybe you want to use something like warning or errors so that it doesn’t fill up too fast and remove important messages.

Something else that we can use, is the show processes. This is very important. I can do show processes just on its own, or I can check maybe for the CPU or the memory. This is very important. If you’re going through like a DoS attack, you’ll see that your CPU utilization will be very high. In this case, there’s nothing happening, everything right now is 0%, 0%, 0%. It’s fine if you have 20, 30, even 40%. But if you’re consistently on, say, 50, 60, 70, then you should know that there’s a problem.

Something I like using, is the sorted option. It will tell me, which process is taking the most utilization. Show processes cpu and then sort it. If we go back to FA0/0, you can see this command here that I talked about, NetFlow. I don’t have any NetFlow collector. But even though I don’t have any NetFlow collector, if I do a show ip cache flow, I can see some information about the flow that it has collected on that particular interface. In this case, you’ll notice something that is currently going on is R2 sending EIGRP packets. This is for EIGRP.

CCNA Quad Instant Pricing – Intense

What I’m going to do is, I’m going to come to R2, I will ping 1.1.1. Let me repeat it for say, 100, to give me enough time to check here. If I do this again, I can see this particular packet here. And you can see it says 100 packets. I can see the protocol ICMP. This is actually very useful. You never know. Like if you’re going through a DoS attack and you consistently see something here taking all your bandwidth or generating a lot of packets, then you may know that, “Oh, this is the host that is causing the problem.”

We’ve gone through a couple of commands. We’ve done show version, we’ve done show run, to show your running-configuration, we’ve done show cdp neighbors, we’ve done show interfaces. What else did we do? We’ve done show logging and we’ve done a couple of show processes. We can just show, show processes on its own or we can do show processes cpu, show processes memory, and things like that. And we’ve also done the show ip cache flow.

This wouldn’t work, this wouldn’t show you anything if you didn’t either use show run interface FA0/0. If you didn’t use this command, ip flow ingress or there’s another command, ip route-cache flow that you can use. It’s kind of like the same thing. It achieves the same thing. So, if you don’t put it on the interface, you will not be able to receive anything. From here, you can actually configure your NetFlow command to export all this information to a particular NetFlow collector.

I hope you have found this lab insightful, and I look forward to the next one.