Try our training for free.

Gain instant access to our entire IT training library for 1 week. Train anytime on your desktop, tablet, or mobile devices.

Cisco CCNA certification proves your professional worth. It tells prospective employers that you can handle the day-to-day work of running a mid- to large-sized Cisco network....
Cisco CCNA certification proves your professional worth. It tells prospective employers that you can handle the day-to-day work of running a mid- to large-sized Cisco network.

The two-exam CCNA process covers lots of innovative features, which better reflect the skills and knowledge you'll need on the job. Passing both exams is your first step towards higher-level Cisco certification, and trainer Jeremy Cioara has mapped these CCNA training videos to the 640-816 test. This CCNA training is not to be missed.

Here's how one user described Jeremy's training: "By the way, Jeremy Cioara has to be by far one of the BEST Cisco trainers I have ever had the privilege to learn from overall. He not only keeps your attention but his energy is contagious and he provides the information at a level where you grasp it rather easily."

The last day to take the 640-816 exam is Sept. 30, 2013. After that date, the only ICND2 exam available will be 200-101. CBT Nuggets has a training course for the 200-101 exam here.

All trademarks and copyrights are the property of their respective holders.
1. Review: Rebuilding the Small Office Network, Part 1 (33 min)
2. Review: Rebuilding the Small Office Network, Part 2 (28 min)
3. Review: Rebuilding the Small Office Network, Part 3 (23 min)
4. Switch VLANs: Understanding VLANs (16 min)
5. Switch VLANs: Understanding Trunks and VTP (39 min)
6. Switch VLANs: Configuring VLANs and VTP, Part 1 (35 min)
7. Switch VLANs: Configuring VLANs and VTP, Part 2 (39 min)
8. Switch STP: Understanding the Spanning-Tree Protocol (28 min)
9. Switch STP: Configuring Basic STP (21 min)
10. Switch STP: Enhancements to STP (29 min)
11. General Switching: Troubleshooting and Security Best Practices (29 min)
12. Subnetting: Understanding VLSM (18 min)
13. Routing Protocols: Distance Vector vs. Link State (26 min)
14. Routing Protocols: OSPF Concepts (30 min)
15. Routing Protocols: OSPF Configuration and Troubleshooting (39 min)
16. Routing Protocols: EIGRP Concepts and Configuration (32 min)
17. Access-Lists: The Rules of the ACL (27 min)
18. Access-Lists: Configuring ACLs (34 min)
19. Access-Lists: Configuring ACLs, Part 2 (48 min)
20. NAT: Understanding the Three Styles of NAT (20 min)
21. NAT: Command-line NAT Configuration (35 min)
22. WAN Connections: Concepts of VPN Technology (33 min)
23. WAN Connections: Implementing PPP Authentication (34 min)
24. WAN Connections: Understanding Frame Relay (28 min)
25. WAN Connections: Configuring Frame Relay (30 min)
26. IPv6: Understanding Basic Concepts and Addressing (34 min)
27. IPv6: Configuring, Routing, and Interoperating (23 min)
28. Certification: Some Last Words for Test Takers (13 min)
29. Advanced TCP/IP: Working with Binary (25 min)
30. Advanced TCP/IP: IP Subnetting, Part 1 (55 min)
31. Advanced TCP/IP: IP Subnetting, Part 2 (22 min)
32. Advanced TCP/IP: IP Subnetting, Part 3 (19 min)

Review: Rebuilding the Small Office Network, Part 1

Review: Rebuilding the Small Office Network, Part 2

Review: Rebuilding the Small Office Network, Part 3

Switch VLANs: Understanding VLANs

Switch VLANs: Understanding Trunks and VTP

Switch VLANs: Configuring VLANs and VTP, Part 1

Switch VLANs: Configuring VLANs and VTP, Part 2

Switch STP: Understanding the Spanning-Tree Protocol

Switch STP: Configuring Basic STP

Switch STP: Enhancements to STP

General Switching: Troubleshooting and Security Best Practices


So you're sitting at your desk on a cheery Friday morning and your phone rings, you pick it up and answer, hello. The person on the other and says hey this is John over in the sales department, how are you doing and you'll say good and he'll say I'm having problems. My computer


I can't do anything, the email doesn't work, the internet doesn't work, you know, I don't know what to do, but I do know that in the lower hand corner, you know by the clock in Windows it has this little picture of the computer with an X over it. I think that means something's, something's


bad. So stop right there, pause on a Friday; what goes through your mind as somebody describes to you that in Windows there's a little computer with an X over it in the lower right hand corner by the clock. Well you may be thinking oh it must be network


disconnected; it could be a port shut down; it could be a bad network card; there's a lot of things that should immediately shoot through your mind as you get more and more experience in the CISCO world and that's what I hope to give you as you walk through this video, is just a switch troubleshooting thought process; how to think through problems as they come up.


I will then show you from my experience some common troubleshooting areas for the switched network that you may run across. Finally, the layer two world, the data link layer switches, are one of the softest squishiest areas for security in the network world today. Now that is changing because there's been so much focus


on firewalls and internet security, that a lot of people have left switches behind. As I mentioned that is changing and I want to show you some of the best practice from CISCO security recommendations for your switch network. When troubleshooting a switched network, the number one thing that can help you is to be familiar with that network and you can partner that was the number two on the screen, absolutely have an accurate network diagram. Those two things combined


together will give you 90% of your troubleshooting. For example, you've seen just going through this series, the network diagram we've been using has evolved, it's a living diagram. As we add trunks to the network, we show lines connecting, we label them trunks, we add Vlans to the network, we show what ports are in the Vlans, we show WAN links, we show IP addresses. In a CISCO admins life, the network diagram is the


lifeline of the network. If you let that go then troubleshooting becomes just a nightmare no matter what. So troubleshooting switch networks thankfully with those two things in place, with familiarity, that's a tough one to say and inaccurate network diagram, it should not be too bad. There's not too much they can go wrong at layer


two. Now don't take that to say that there's nothing bad that can happen at layer two, there's all kinds of crazy stuff that can go on, but if you are familiar and have an accurate network diagram, your 90% of the way there. Once those two pieces are in place whenever


an issue comes up you need to, I guess, learn to work logically. This is the best way I can say it, is this is something that only comes with experience. I know we're talking at the CCNA level, but as you sit in network environments and you will get experience as you get your CCNA, as you move into a more more network realms, you'll have experience which just common things that come up. And you'll be able to work logically from


the bottom up and what I mean by that is with the OSI model. Now the reason I hesitate to say, use the OSI model for troubleshooting, is because sometimes it just doesn't make sense. For example somebody is saying, hey I can get to these websites, but I can't access the server, I don't no can you help me out? I mean step one of that isn't to go, well let's think is your network cable connected? Is there a break in the line? You know insert professional voice man there, I don't know where that came from. So you don't, you think okay they're


surfing the net, they're not able to get to that server, okay, maybe there's some routing issues between the Vlans, maybe other security between the Vlans that's blocking that person from the server. So when you're working logically, you need to take the problem that's being described and then apply what you know about the network to be true. Meaning if they're


able to surf the internet that means they are physically connected; they're getting out of the network; NAT is working properly. All those kinds of things instantly come into your mind, but don't have to say that nothing really happens at the physical layer. There are times where I'll be troubleshooting a problem


for an hour and then come to find out, oh it's a button on the laptop that turned off the the network card or something like that. You know it's just one of those kinds of issues. So working logically from the bottom up, combining the experience in the familiarity with your network is the best troubleshooting process for any network.


I'm glad I talked about that fault process first, because I was just thinking, I am going to give you some common troubleshooting issues that you may run into and some of the solutions. This is not one of those lists to memorize and say, okay if that happens I do this. It needs to blend into that logic and that train of thought


to think, oh I've heard of something like that before, let me check these general areas. So here some of the common issues. First off on the port, these are with the physical port themselves. Number one cabling issues, never hurts to just verify that things are connected right. Second, verify that speed and duplex


are auto negotiating correctly. As I mentioned in some of the previous videos, speed and duplex is set to auto by default and it's got, you know, 90-95% success rate, so it's pretty good, but that means that you will occasionally have a duplex miss negotiation, if that's the word, but it's never the speed, the speed always works out okay. It's the


duplex, one side will be set to half, the other side will be full. What will happen is you will get very poor performance from that device, because you're dropping tons of packets. Now on some of the switches in some, I guess, devices that access the network a lot, high traffic devices, it will send so many errors to the switch, the switch will shut down the port or technically put into a error disabled state. So if it does


that, that's the better in my opinion, because their port goes out and they'll call you right away and you can go and go, oh I see you've got a ton of errors, let's figure this out. So hard coding the speed and duplex on those ports is the best bet. Finally check that the assigned Vlan has not been deleted.


So here's the scenario, you've got a PC that's plugged into a switch and it's assigned a Vlan 10, but Vlan 10 has been de-commissioned, meaning the company is no longer going to be using Vlan 10 for their network. Well you may think you've moved all the devices out and then remove Vlan 10 and what will happen to this port is it becomes kind of a nothing port, it becomes lost literally. The light on the front of the


port is your best indicator because it will immediately turn amber, there will be an orange color, so you can just look at the port and go oh there's a problem, do some show commands. If a computer is assigned to a port or I should say a port is assigned to a Vlan and that Vlan no longer exists, the port goes into this limbo state, where it just can't access anything.


It's not like it goes back to the default Vlan or anything. So you'll know if the Vlan has gone, because the device that's attached cannot access anything. Now we move into the spanning tree issues. Spanning tree issues if you have an issue will be a major one. With spanning, well I shouldn't say


always, but most of the time it's going to be like network down, fire in the hole, people screaming and all that kind of stuff. It's a major issue. I guess the thing that I can tell you that you'll be able to see if there's a spanning tree issue, is if you walk into the IT room and look at the switches, they'll all be just blinking like mad.


If you've worked in a network for while, you'll get the general feel for just how things look when you walk into the IT room. You know you'll see some lights blinking here and there. You know some lights are going to be green and solid and so on, but when you go into a spanning network where there's a spanning tree issue and I should say more specifically a loop has occurred, where there's, there's looping packets. You'll know it because


you'll walk into that IT room and it just looks like a Bon Jovi light show, it's just wow, you know everything is going crazy and that should immediately trigger in your mind something is very wrong, as in you know probably a spanning tree issue. What's happening is all of your switches will be pegged, you know 90 to 100% processed utilization. All the PCs and networks will probably be down, although some may get some access but very slowly because everything is so saturated.


So to solve the immediate issue, grab your network diagram, remember that familiarity and disconnect your redundant links. If a loop has occurred that means spanning tree is broken down somewhere in the network, find the redundancy and start disconnecting it.


That will eliminate the immediate issue and at least get the network back and operational. Sure redundancy isn't in place, but that's a side not. We don't need redundancy if the networks are down. So from their ensure all links are reflected on a network diagram. There is plenty of times, it has


happened to me, where people just start daisy chaining hubs to another hub to another hub and so on. Now we don't get too deep into spanning tree in the CCNA level, but spanning tree has an effective radius, meaning distance of about five devices. So when you have a switch in your network,


if you plug another switch into it and daisy chain another switch and daisy chain another switch, you know what I mean, this daisy chaining effect. Well you can get about five away before spanning tree just starts breaking down. So somewhere around here if you accidentally connect


something like that, spanning tree won't be able to detect a loop then chaos breaks out. There's actually, I read this; ah I wish I could remember what it was. There's this great White paper about a hospital. It's literally a CISCO hero story where there's this hospital where this exact system occurred. Where they just,


you know the network kept growing and somebody, just not even thinking, plugged this switch and plugged in another computer and the entire hospital network went down. Now when you're talking hospitals, you're talking life support systems; you're talking doctor notification systems, I mean that's a network right there where people are depending literally and lives depend on the network and CISCO got the call that the whole hospital had gone down. This White paper, I've got to find it for you, hang on hand on;


I've got to write this down. I am opening a little notepad document over here, find hospital White paper. It's a great read, I'm telling you, because I'll give you the climax of the story. CISCO literally throws a bunch of CCIE's on a plane from San Jose, flies them out to this hospital. Within, it's some goofy amount of time,


like five hours, they completely gut out the entire hospital network and put in all new CISCO equipment. They're not even troubleshooting the problem, they're just gutting the thing and putting new CISCO gear in to bring the network back on line, because you know lives are dependent on this. So, anyway it ends up being that the whole story


is that it was a spanning tree issue that took the hospital down. So what was I talking about, here we go; so links are reflected on the network diagram. Make sure the root, oh that's how I got on that story. There's a lot of times where people will start daisy chaining things and network diagrams never get updated, that's my point in telling you that. A lot


of times employees say, oh let me hook you up here Fred, they just daisy chain a switch, not knowing of the ramifications. So again port security is big on that one, we'll talk about that later time. Alright, ensure root bridge selection is appropriate. Meaning, find the core switch


of your network and elect that as your root bridge. Make sure all switches are running rapid spanning tree protocol if possible. Meaning, if you have a fairly modern network where all the switches are newer so rapid spanning tree will recover much faster.


Alright enough on spanning tree. Vlan and trunking issues. Vlan issues, number one watch out for native Vlan mismatch. Now again the native Vlan is what a trunk port is assigned to if it's not trunking. It was for, if you had a hub in the middle of two switches. So if this is a trunk port the native


Vlan on each of these should be the same by default on CISCO switches the native Vlan is one. If you have a native Vlan mismatch, the switch will start reporting it on the screen. It will say hey, native Vlan mismatch detected and that would be maybe this one is Vlan 10 and this is Vlan 1. What happens if you have a native Vlan mismatch, is that the Vlans will bleed together, meaning traffic from Vlan 1 and broadcasts in Vlan 1 will bleed into Vlan 10 and Vlan 10 broadcasts will bleed into Vlan 1. You can have issues like IP addresses from the wrong sub-net being assigned, because DHCP requests end up flying to the wrong Vlan. So


just make sure that on your trunk ports, the native Vlan is set to be the same. If you need more info on the native Vlan, it's back into the Vlan nuggets. That's where we talked about that originally, so I don't want to rehash that whole thing here. Hard code trunk ports to on, you might remember


that by default every port of a CISCO switch is set to dynamically negotiate. Meaning if a computer plugs in, it becomes an access port, if another switch is detected, it becomes a trunk port. That's not good for security and just management purposes so just hard code things. Hard code all your


trunk ports to on, on the ones who want to be trunks. Verify IP addresses assignments in a Vlan. Make sure that the Vlan sub-net is the same sub-net that all the PC's are ending up with and use ping and trace route to diagnose routing issues. Those are your


best friends when trying to figure out what's wrong with maybe your route around the stick that gets you off the Vlan. Lastly VTP issues; Vlan trafficking protocol. Number one, verify your trunks. VTP is the Vlan trunking protocol, it's used to replicate Vlans and I mentioned it when we were talking about before, VTP is not a trunking protocol even though it's in the name, it just replicates. But the reason it got that name is because


VTP only works over trunk links. So verify that you have trunks. Second, verify all your the VTP info. Make sure the domain name, the password, the version numbers and VTP modes; you might remember server client or transparent mode for VTP. Verify that all those things lineup and last


but not least you don't find this in many CISCO documentations, but to completely flush all Vlan information off a switch, you want to go into privileged mode and type in delete flash:Vlan.dat. All the Vlan information is stored in that file. You'll never see Vlan information


in the running config. If you do a show run, you'll won't see any VTP, nothing, it's all stored in Vlan.dat, it's kept separate. So if you want to truly flush a switch, just try again delete that file and reboot, that will clear out all the Vlan information.


Now let's take a turn and look at switch security. Actually before we do I want to bring up that hospital White paper I promised I would find. I sort of found it, I can't find the original paper itself. There was a PDF and if you find that, that would be awesome if you could email me. But right on here on Google, I want you to go to Google


and type in CISCO hospital White paper spanning tree. It's a strange string, but that will find it. These first two links are the same article. It's a shorter version of the original full article which is called All systems down. Actually it's very well


written, it's almost like a suspense novel. They essentially walks through how the hospital network failed and the four days that it took to get it up and running. Actually and I read through the article again, I couldn't stop myself. There was one thing I just


misspoke on the previous slide, the distance that spanning tree can go is seven switches not five. I said five, so they actually went beyond seven switches at this network in multiple links. So it blew everybody's mind. Alright, with that let's turn back to switch


security. Most of the focus in networks today and I think I mentioned this at the beginning of this video, is on the network perimeter. Just about every article and magazine is all talking about internet security and how you need to protect your internal network from the internet. So everybody focuses


their eyes right here on this boundary, between the internet and the internal switched world. Now the problem with that is, first off it's not a problem, you definitely need internet security, but it leaves the inside of your network like a squishy oreo center. If somebody gets in, then they just


have fluff to cut through, there's no security there to stop them. Now thankfully wireless has actually added a lot of eyes to the internal network, because wireless broadcasts your internal network to the rest of the world, so we've had to increase the security. So


here is the security checklist that CISCO recommends you go through. Number one is physical security. If somebody can get to your switch physically they can do a lot of damage very quickly. As a matter of fact, I am not to sure how many of you know this, but on a CISCO stackable switch, and when I say stackable, I mean just the normal small switches you buy for networks, not the big chassis ones like the 6500 series, but just a normal switch. If you hold the button on the front of the switch, it's the little mode button for 10 seconds or more, the switch will automatically erase all its configuration and go back to the factory default. Now you can turn that feature off, but most people


don't even know that feature exists so just about every switch that I've seen leaves it on. So if somebody busts into the IT room or just gets to the switch; we'll not make it so dramatic and holds one of those buttons for 10 seconds, they can completely nuke the config. So physical security is a


must. Second, is set passwords and logon banners. We talked about that already on console ports, on VT wi-lines, enable secret. A third is disable the web server. On older IOS last versions, the web server feature is enabled by default and even on some of the newer versions. To disable


it go into global config mode and type in no ip http server. That shuts it off. You can also type in no ip http secure. This one doesn't have it, there's actually on other IOS versions the secure server, which is the http S version. That one is not on by default, but if you want to shut down both web servers that's how you do it. The web interface is most of the


time not useful anyway. Now some of the newer switches have a full-blown graphic interface that show the switch and you can actually point and click, it's very pretty, but most of most of the older ones don't have that. When I say older I mean a year or two old. So they'll just have a text window


where you can start executing commands and there are some vulnerabilities that have been found in that web server. So just turning it off is the best bet. Limit remote access subnets and we'll talk about access lists in a moment, but what that means is don't let people telnet into the switch or SSH into the switch that don't belong there. If somebody can telnet to the IP address of the


switch they can just randomly begin trying passwords to break in. By using an access list, you can say only this IP address or only this subnet of addresses is allowed to telnet to the switch or SSH to the switch. So when possible, block it down that way. Next use SSH


rather than telnet. I will fully admit to you that SSH is more inconvenient, not only because it's a pain to set up, but also because telnet is just about embedded in every operating system. You go to Windows and open a command prompt and you've got telnet. You don't have to download


puddy or or tera term in order to get SSH capabilities. So telnet is a little bit more inconvenient, but SSH is far more secure. Next configure logging. Most people will just leave logging at default. Which is on the console. What that means is you see right there, I'm connected to the console port, every time you do something it will report something to the screen or any time an interface goes up or shuts down, it will report to you this interface is up or down. All the reporting


is sent to the console port. Now the best bet to track that, is to go into global config mode and type in logging. I'll show you the simplest way; logging buffered and then type in a memory level. So we'll just say 64,000. What that does is allocate 64,000 bytes which is a decent amount it's not a huge amount, I'd say it will hold maybe depending on the type of network, but maybe three, four, five days of logging information on what's happening on a switch to the memory. So you can then go back and type in show log


and it will show you all of, well, see; you can see right there 64,000 bytes. No messages have been generated yet. Here, let me do this. Let's generate some messages. I'll do a shut down, no shut down. There we go, it's back up, interface 0/24 shut down, no shut down, just you know get some messages going on here, there we go. Now I'm going to go back and do a show log.


Full command is show logging and you can see all of the stuff that happened is saved in that memory buffer. So I can go back and see what's going on. Now of course there's going to be more interesting stuff than interfaces going up and going down on a full production switch, but that is setting up logging.


The other way that you can log, is you can type in logging from global config mode and type in the IP address of a remote host. Now that remote host could be just a PC running, I'll show you a handy program of the day. It is, let's see if I can remember, let me open a new window


here. It's kiwi syslog;; right there, Kiwi Syslog. Now if you go here you'll see right here a freewee, I can't even say it, a freewee, a freeware Syslog Daemon and when you click on that you can download this for your PC. It is just a pretty nice logging system that will receive these messages and you can put them in a table format; you can search through them; you can find them; there in a buffer and all that kind of stuff. So you install that and run on a PC and then


you go to your command line and point your switch to the PC running the Kiwi Syslog and that will configure logging. Now down at the bottom we will see limit CDP reach when possible, limit where CDP is running. Now there's two ways to do that. Go into global config mode and type in no cdp followed by run, which turns off CDP on the switch as a whole, thus the global config mode. That will disable CDP everywhere and you will no longer


be able to see the switch using the CISCO discovery protocol. You can also go under each interface if you'd rather do it on an interface by interface basis and type in no cdp enable. Now the reason that is a good security practice, is because CDP is something being originated by the switch. Meaning the


switch is going to send out CDP broadcasts once every 60 seconds out of every single port that it's connected to. Somebody can just open up a packet sniffer on their computer and receive the CDP information, which tells them the name of the switch; the IP address of the switch; the IOS version it's running; you know all the CDP information we talked about; in was that in this series, maybe even the previous series, that you can see on all the different devices just in case it was the previous series.


Let me just make sure. I'll do a show cdp neighbors, that should help refresh your memory, show cdp neighbors detail. Seeing what is connected to this device via CDP. So a lot of times it's good to turn that off. Now you notice I have, when possible, that's because


a lot of the new CISCO equipment like there IP phones need CDP to operate correctly or to operate efficiently I should say. So it may not be possible to turn off CDP. Last but not least, use BPDU guard on port-fast ports. Now you might remember port fast was the utility that essentially disabled spanning tree.


So if you plug in a PC, it immediately goes online rather than waiting for the 30 seconds that spanning tree takes to make report go active. Now it's always best to couple that with BPDU guard. Let me first show you the syntax, then I'll explain what that is.


You go under your interface that is enabled for port fast, you type in spanning tree followed by bpduguard. What it says is don't accept BPDUs on this interface. Now if you think back, if you're thinking BPDUs, that sounds familiar, it's from the spanning tree videos earlier in the series. Spanning tree


uses BPDUs to announce itself. So what BPDU guard does is if you have a switch enabled for port fast and you connect another switch, well that violates the port fast agreement. Port fast is only for PCs. So if a BPDU comes into that port, the switch realizes that another switch has been attached to that port and it will immediately shut down this interface. BPDU guard


will take it down. So that's very handy to help prevent a lot of loops. It also helps prevent this kind of scenario. Somebody plugs in a hub under their cubicle and daisy chains to another port in another cubicle which links back to the switch. Well the switch will send out a BPDU out this port,


go through the hub, through another hub and it will come back into itself. BPDU guard detects that and will shut down both of those interfaces because it detects a loop in process. So that is a great one. I want to make sure you don't confuse that with BPDU filter.


BPDU filter is a dangerous one. It says don't accept or I should say don't send or receive BPDUs on this interface. The reason that's dangerous is it will ignore BPDUs coming on that port, it doesn't shut the port down. So somebody could set something like this up with BPDU filter turned on and the switch would never detect the loop and that's what would cause one of those hospital incidents that take the network down. That wraps up the troubleshooting and security practices


for our switch network and that wraps up switches for this entire video series. We are not going to talk about switches anymore. It's going to be all router concepts from here on out. So let's recap. We saw the switch general troubleshooting process looking at the OSI model as a guide, using a familiarization with your network and a logical network diagram to help you out. We then saw alot of the common


troubleshooting areas for our switch networks; things like the port issues and spanning tree issues. And we saw securing the switch network, the best practices that CISCO recommends to lock down the inside of your network a little tighter than leaving it as is, which is wide open. I hope this has been informative

Subnetting: Understanding VLSM

Routing Protocols: Distance Vector vs. Link State

Routing Protocols: OSPF Concepts

Routing Protocols: OSPF Configuration and Troubleshooting

Routing Protocols: EIGRP Concepts and Configuration

Access-Lists: The Rules of the ACL

Access-Lists: Configuring ACLs

Access-Lists: Configuring ACLs, Part 2

NAT: Understanding the Three Styles of NAT

NAT: Command-line NAT Configuration

WAN Connections: Concepts of VPN Technology

WAN Connections: Implementing PPP Authentication

WAN Connections: Understanding Frame Relay

WAN Connections: Configuring Frame Relay

IPv6: Understanding Basic Concepts and Addressing

IPv6: Configuring, Routing, and Interoperating

Certification: Some Last Words for Test Takers

Advanced TCP/IP: Working with Binary

Advanced TCP/IP: IP Subnetting, Part 1

Advanced TCP/IP: IP Subnetting, Part 2

Advanced TCP/IP: IP Subnetting, Part 3

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus
16 hrs 32 videos


Basic Plan Features

Speed Control
Included in this course
Play videos at a faster or slower pace.

Included in this course
Pick up where you left off watching a video.

Included in this course
Jot down information to refer back to at a later time.

Closed Captions
Included in this course
Follow what the trainers are saying with ease.

Files/materials that supplement the video training

Premium Plan Features

Practice Exams
These practice tests help you review your knowledge and prepare you for exams.

Virtual Lab
Use a virtual environment to reinforce what you are learning and get hands-on experience.

Offline Training
Included in this course
Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching
Included in this course
Develop and maintain a study plan with assistance from coaches.
Jeremy Cioara
Nugget trainer since 2003