Cisco CCNA in 60 Days

Welcome to the deep dive. This is where we take your sources, dig into them and really pull out the most important insights. That's right. Today we're kind of pulling back the curtain on how the Internet, you know, how all our modern networks actually work underneath it all? Yeah, the real guts of it. Yeah, exactly. You click a link, send a message, watch a video. It feels instantaneous, like magic, doesn't it. It really does. Well, it's definitely not magic.

Our mission really is to give you a shortcut. This stuff can be incredibly dense, so we're extracting the let's say, the must know parts and maybe some surprising bits from a great resource, the Cisco CCNA and sixty Days Learned Dot pdf book.

Yeah, and it's got a kind of cool backstory. The original author, Paul Browning, was actually an ex police officer in the UK. Oh really, yeah, taught himself it, wrote the first version because he needed it. But then importantly he brought in these dual CCIE network architect people like Daniel Gersh Daryl Brunnick for ITAFA the people who actually do this stuff day in, day out, exactly as the

The goal is you walk away feeling informed, maybe have a couple of aha moments, and just get a better feel for what's happening behind the scenes without getting totally overwhelmed.

Ideally. Okay, so let's start at the beginning, maybe how things used to be before we had these intelligent devices. We had hubs. You call them the network's loud speaker. That's a good way to put it.

Yeah, hubs were really simple, basically multiport repeaters. Signal comes in one port, it gets boosted, and then just blasted out of every other port. Didn't matter who it was for.

So if my computer sends something to yours, everyone else plugged in got it too.

Everyone got it. Which leads to the biggest problem. Yeah, one huge collision domain, right.

Like shouting in a crowded room.

You said, Yeah, chaos total, Only one device could really talk at a time without signals colliding, and they only worked at half duplex. Couldn't send and receive simultaneously. Performance was well, not great.

Okay, So hubs were noisy and inefficient. Then came switches, and here's where you said it gets interested. Maybe counterintuitive switches increase collision domains.

Yeah sounds weird, right, but it's a very good thing. See with the switch, each port essentially becomes its own collision domain. Traffic is isolated.

Uh okay, so instead of a shouting match, it's.

More like like a smart telephone operator maybe, or an efficient post office. It directs traffic precisely.

How does it do that? How does it nowhere to send things?

So switches use something called a content addressable memory table a CAM table, and this is usually stored in a special chip and ask to make it super fast?

Okay. The switch listens to.

The traffic and learns the unique hardware address the emmelia address of whatever device is plugged into each port.

It builds this table, so.

When a frame comes in in, the switch looks at the destination MSc address, checks its CAM table and says, ah, that device is on port five, and sends the frame only out of port five.

Not broadcasting it everywhere like the hub did.

Exactly, huge improvement and efficiency less unnecessary traffic.

Better security makes total sense. So switches are great for connecting local things BCS, printers, servers, and you mentioned segmenting networks with VLANs, which I definitely want to get back to.

We will.

But for basic setup, you just need to give it a name, a host name, and set up promote access right, prefer secure.

SSH precisely, keep it simple but secure. Now, if switches handle the local traffic, routers are the big navigators. They connect different networks.

And you said learning about routers is like what half the CCNA curriculum easily.

Yeah, it tells you how crucial they are. They're the devices that really stitch the Internet together, connecting all these separate local networks.

So they don't just connect networks, they actively learned about them. They do.

They learn routes, They exchange routing information with routers, and they figure out the best way to get packets from networkA to network B, whether that's internal networks or out to the wider Internet.

Okay, walk me through that. A packet arrives at the router destined for somewhere else. What happens step by step?

Okay, So first the router receives the frame off the wire and needs to look inside, so it performs decapsulation. It strips off the layer two frame, header and trailer. That information was just for the previous.

Hop, right, like the local delivery instructions exactly.

Then it looks at the layer three packet inside, specifically the destination IP address, the ultimate disc the ultimate destination. Yes, it consults its routing table to find the best path towards that destination IP. Then crucially, it re encapsulates that layer three packet into a new layer.

Two frame, a new frame.

Why new, because the next hop might be over a different type of network link. Maybe it came in over ethernet, but it's going out over say an older ceial link using HDLC. The frame format needs to match the outgoing link.

Ah, okay, different local delivery instructions for the next leg of the journey, You got it.

And then it forwards that new frame out the correct interface.

So this leads to that really key point, that aha moment you mentioned. Yes, this is fundamental.

As a packet travels across multiple networks, multiple routers, the source and destination IP addresses inside that packet they never change.

They never change. Okay, But the layer two.

Mmy addresses in the frame. They change at every single hop between routers or other intermediary devices.

Right, the envelope dress stays the same, but the mail carrier changes at each sorting office.

Perfect analogy. The IP address is the final house address. Theme address is the specific person carrying the mail between post offices. Right now, That dynamic is what makes global routing work alongside local delivery.

And interacting with these routers like switches, usually means using the command line interface the CLI. It has different modes it does.

It's hierarchical. You start in user mode, which is very limited router. Then you enable to get to privileged mode router hashtag where you can view things and do basic tests. To make changes, you go into global configuration mode config T giving router configure hashtag, and from there you might go into more specific modes like interface configuration, router configure hashtag, or router configuration.

Kind of nested levels of control exactly.

It prevents accidental changes. You use commands like exit to go back up a level or credil plus z to jump straight back to privileged mode.

And for new folks navigating this.

Oh, the question mark is your best friend type it anywhere. It shows you available commands or options. Tab completion is also essential. Start typing a command, hit tab, it finishes it for you, saves typos, and show history is handy to see what you type before life savers.

I bet okay. So we have the devices, hubs, switches, routers. We know how they physically move data. Now let's talk about the language they speak, these models OSI and t ACPIP. What problem did they solve? Great question?

Before these models, networking was kind of the wild West. Every vendor had their own way of doing things, and getting equipment from different companies to talk to each other was difficult, a nightmare probably pretty much. So these models OSI being more theoretical with seven layers and TCPIP being the practical one, which this go often shows as five layers. Now they created a common framework, a blueprint.

A standard way of thinking about network functions.

Exactly, they divided networking into logical layers physical data, link, network, transport, application, and so on. This modularity means vendor A can focus on making a great layer two switch, and vendor B can make a great layer three router, and they can still work together because they adhere to the same layered rules.

And it allows innovation at one layer without breaking everything else.

Absolutely, it's all about interoperability, and.

This concept of encapsulation and decapsulation fits right in here, doesn't it perfectly.

As data moves down the layers on sending device, each layer adds its own header, like putting the data in an envelope than a bigger envelope, etc.

That's encapsulation, wrapping it up, wrapping it up.

Then as it moves up the layers on the receiving device, each layer unwraps its corresponding header, processes the information, and passes the rest up decapsulation.

Okay, so let's look at the addresses used at these layers. Layer three IP addressing the global address. We started with IPv four.

Right, the original thirty two bit addresses revolutionary at the time, but we ran into a problem pretty quickly. With the massive explosion of computers and Internet connected devices.

We ran out of addresses, basically started running out.

Yeah, address exhaustion became a real issue. We had addressed classes initially ABC with defall masks, but we needed more flexibility.

Which led to subnetting exactly.

Subnetting was this clever trick. It let network admins steal bits from the host part of the IP address to create more network segments or subnets within the originally allocated block.

So you could take one large network and carve it up into smaller, more manageable pieces, like taking a large plot of land and dividing it into smaller lots. Good analogy.

It helped use the available addresses more efficiently and allowed for better network organization and security. You know, calculating subnets can be tricky, hence things like cheat sheets like figuring out which subnet one ninety two point one sixty eight point one zero zero two six.

Belongs to right. But even subnetting was just delaying the inevitable with IPv four exhaustion, which brings us to IPv six the future, well, the present and future. Why the big push to migrate? Obviously, there are way more addresses one hundred and twenty eight bits versus thirty two that's.

The headline feature, almost unlimited addresses. But IPB six offers more. It has a simpler packet header, which routers can process more efficiently. It eliminates broadcast traffic altogether.

No more shouting in the room, No more shouting.

It relies heavily on multicast instead, and it has built in support for stateless auto configuration, making it much easier for devices to get an address automatically.

Okay, simple, faster, bigger address space, easier configuration sounds good, but the addresses look intimidating. That's adecimal. They do look different. They use exitesimal numbers zero nine and letters af eight groups of four hex characters separated by colons, like two thousand one point point zero dB eight point eight five eight three point zero zero zero zero zero zero zero zero point a two e point zero three seven zero point seven three three four. That's a mouthful lots of

Three four precisely makes them a bit easier than handle, and IPv six has different address types too. There are link local addresses. They start with fe eighty point en and devices use them automatically to talk to other devices on the same physical link for things like neighbor.

Discovery, so local chat only. Right.

Then you have multicast of russes starting FS zero zero point eight, used extensively for one to many communication. IPv six uses multicasts for things arps to do in IPP four and any cast is interesting, same address on multiple devices, your traffic goes to the nearest one.

It's more of a concept for CCNA level though, and auto configuration. You mentioned stateless and state full.

Yeah. Statefle is like DHT and IPv four where server hands out addresses DHCPv six stateless is cooler. A host listens for router advertisements containing the network prefix, then it basically creates its own unique address by combining that prefix with its own MSSU address slightly modified and what's called EUI sixty four.

Format clever self sufficient addressing pretty much. Okay, So that's layer three. Down.

At layer two we have MAAC addresses, the physical hardware address.

Burned into the network card, unique to each device.

Ideally ideally yes, the data link layer address. But how does your computer know the MAC address of, say, the local router when it only knows the router's IP address.

Good question. It needs to translate IP to MP somehow for local deal.

And that's ARP Address Resolution Protocol. It's the local translator.

How does it work?

So when your PC wants to send a packet to the router's IP, it first checks its own AARP cash a little table mapping IPS to MLC.

It already knows uh huh.

If the router's MH isn't in the cash, your PC sends out an ARP request. This is a broadcast message saying, hey, whoever has IP address one nine to two point one sixty eight point one on one, please tell me your my address.

Shouting again, but just locally, this time locally exactly.

The router sees this broadcast, recognizes its own IP and sends an ARP replied directly back to your PC, saying that's me, Here's Miami address. Your PC then adds this mapping to its RP cash and can now build the layer two frame properly.

Got it, And that explains why sometimes the first ping to a device fails. That's often the reason.

Yeah, you'll see a period maybe for the first ping attempt, indicating a timeout while ARP does its thing. Then the next pings succeed with exclamation marks B. The ms isn't now cashed. These cashes don't last forever though, they time out, usually after a few hours to keep things fresh.

Okay, ARP handles local IP TOMAC translation, but going back to the IPv four address shortage, ARP doesn't solve that. That's where NAT comes in, right, Network address translation absolutely essential. NAT.

Your analogy of the color tokens was spot on. You have loads of private internal addresses you can use freely the blue and yellow tokens, but you only have a few or maybe just one public IP address to access the global Internet, the scarce green tokens.

So NEAT is the gatekeeper managing those green tokens.

It's the exchange mechanism. When your internal device needs to talk to the Internet, the GNAT router swaps out the private source IP for a public one. Its fundamental purpose was and still is conserving those precious public IPv four addresses.

And there are different flavors of net A.

Few main types. Yeah, static net is a simple one to one mapping. This private IP always uses that public IP. Good for hosting a server. Okay, Then you have a NAP where you have a pool of public eyps, and internal devices grab one from the pool as needed, first come, first served until the pool runs out right. But the most common type, especially in homes and small businesses, is NAT overload, often called PAT port.

Address translation the CAT. Yeah.

This allows many internal devices to share a single public IP address. The router keeps track of connections by using different source port numbers for each internal device's session.

Ah, so it uses the port number to differentiate the conversations sharing that one public IP precisely. It's incredibly efficient for address conservation. And you mentioned a common troubleshooting issue with NAT, something easily forgotten. Oh yeah, it's almost a classic.

Nine times out of ten, someone's configured the NAT rules, but they forgot to tell the router which interface is connected to the internal network and which is connected to the external network.

You need those.

Ipnet inside and IPNAT outside commands on the interfaces.

Simple mistake, big headache, Good tip. Okay, let's shift gears to organizing networks within an organization. V lance Virtual.

Lands d lands are huge, really fundamental for modern network design. They let you take one physical switch and logically chop it up into multiple virtual switches.

So devices plugged into the same physical switch can be in different logical networks exactly.

You can group devices by department, say sales on VLAN ten, engineering on VLAN twenty, even if their desks are scattered across the building and plugged into different switches. Or you can separate voice traffic onto its own VLAN for quality of service and.

The key benefit here security wise or traffic.

Wise, each VLAN is its own separate broadcast domain. Remember how hubs were one big broadcast domain and switches made each port its own collision domain. Well, vilains create broadcast boundaries at layer two. By default, traffic from VLAN ten cannot reach VLAN twenty and vice versa. Broadcasts sent in VLAN ten only go to other ports in.

VLAN ten, So improve security through isle and less broadcast noise flooding the whole network.

Absolutely, but it means each vland needs its own IP subnet, like one ninety two point one sixty eight point zero two four for v LAN ten and one ninety two point one sixty eight point twenty day point zero two four for VLAND twenty.

Okay, different virtual neighborhoods, different address ranges. But what if sales needs to talk to engineering, how do they communicate between vlands?

Ah, that requires interval routing. You need a layer three device, a router or a multi layer switch to act as the bridge between those IP subnets.

Makes sense. But first, what if I have devices in the same vlan, say VLAN ten, but they're plugged into different physical switches, one on floor one, one on floor two. How does their traffic stay in VLAN ten across the building?

Good question. That's where trunk links come in. A trunk link is a special connection between switches that's configured to carry traffic for multiple VLANs simultaneously.

Like a highway carrying traffic for different destinations.

Exactly when a frame belonging to say villan ten needs to cross the trunk link to the other switch, the first switch adds a tag to the frame that identifies it as belonging to.

Vilan ten, a VLANI tag giant Right.

The receiving switch sees the tag, knows the frame belongs to villaan ten, removes the tag and forwards the frame only to ports assigned to VLAN ten on its side.

So the Vilin identity is maintained across switches. And how is this tagging actually done.

Two main ways. There's an older Cisco proprietary method called isl interswitch link. You don't see it much anymore, Okay, The standard universally used method is i ee atoh two point one Q, often just called DOT one Q. It inserts a small tag into the Ethernet frame header.

Got it? ATO two point one Q is the standard. And you mentioned something with a native lan ah?

Yes, with ATO two point one Q, there's a concept of a native LAN. Traffic belonging to this specific villain is sent across the trunk link untagged by default.

This is villain one untagged. Is that a problem? It can be a security risk.

It's best practice to change the native VLAN to something other than the default VLAN one and make sure it's consistent on both ends of the trunk link. Also, so don't put any user devices in the native VLAN.

Okay, change the native vilan from one. And what about setting up these trunk links? Is it always manual?

You can configure them manually. But Cisco also has a protocol called DTP Dynamic Trunking Protocol. It allows switches to automatically negotiate whether the link between them should become a trunk it's Cisco proprietary though, right.

So we have VLANs for segmentation trunks to connect VLANs across switches. Now back to routing between VLANs. How do we build those bridges?

Several ways? The old school way was to use a physical router with a separate physical interface plugged into the switch for each VLAN. One port for VLAN ten, one for VILAN twenty.

Sounds inefficient, uses up a lot of router ports.

Very inefficient, doesn't scale well. A more common method became router on a stick. Yeah, you use one physical router interface connected to the switch via a trunk link. Then on the router you create logical sub interfaces, one for each VLAN. Each sub interface gets an IP address in that VLAN subnet and understands the eight to two point one Q tags.

Ah. So the single physical link carries tag traffic for all VLANs up to the router, and the router sorts it out using sub interfaces exactly.

The downside is that all intervland traffic has to go up to the router and back down, sharing the bandwidth of that single link.

It can become a bottleneck. Okay, better than multiple physical interfaces, but still potentially slow. What's the modern approach.

Multi layer switches. These are switches that can also perform layer three routing. You create logical interfaces on the switch itself, called switch virtual interfaces or sviis SVIs. Yeah, you create an SVII for each VLAN like Interfaceland ten interface Land twenty, give it an IP address in that VLAN subnet, and the switch can then route traffic directly between VLANs at hardware speed, much faster and more scalable.

So the routing happens right there inside the switch, right inside.

Though sometimes on certain switch models, like maybe a Cisco twenty nine to sixty, you might need to enable a specific routing template and SDM template and reload the switch before it can do layer three routing.

Good to know? And if things go wrong with VLANs or trunking? What are the usual suspects when troubleshooting?

Often it's simple configuration errors. Did you assign the ports to the correct VLANs? Are the trunk links configured correctly on both ends? Same native vland, same allowed VLANs. Physical layer issues of course, bad cables, huh, mismatched VTP settings. VTP is a protocol for synchronizing VLAN databases, and if

If you're not careful. Yikes.

Yeah, VTP needs careful handling and sometimes spanning to reprotocol STP, which prevents loops, might be blocking a port you expect to be working, and amber lade on the switch port is often a clue that STP is involved.

Okay, let's to check there. Finally, let's wrap up with security. We have all this gear, switches, routers, how do wetect them?

The absolute first step, often forgotten is physical security. Lock the doors. Network gears shouldn't be accessible to just anyone. If someone can physically plug into your core switch or console into your router, game over right.

Lock the wiring closet, secure the data.

Center absolutely, Then secure remote access. We mentioned SSH over telnet. Telnet sends passwords and plaintext. Big no no, Always use SSH.

And setting up SSH requires a host name and a domain name on the device right to generate the crypto.

Keys, correct, you need those configured first, Then manage your passwords properly. Use strong passwords obviously, and understand the difference between enable password.

The less secure one.

Yeah, it's stored less securely, potentially visible in the configure. If you haven't encrypted it, use enable secret instead. It uses stronger MD five hashing and always takes precedence over enable password if both are configured.

What if you forget the enabled secret password locked out?

Not necessarily, but it's a hassle as a password recovery procedure usually involves interrupting the boot process and changing a configuration register value specific to the device model.

Best not to forget it. Good advice. What other basic security hygiene should be done?

Use the service password encryption command. It applies a weak encryption to passwords like the enabled password and user passwords in the configuration file, just so they aren't sitting there in plaintext if someone looks at the configure. Better than nothing. Okay, centralize your logging. Configure devices to send cislog messages to a central server. You need logs for troubleshooting and security auditing, and make sure those logs have accurate time stamps right.

Use service time stamps, log daytime, local time showtime zone.

Exactly, which also means you need accurate time on the devices themselves. That's where NTP Network Time Protocol comes in. Synchronize your device clocks to a reliable NTP server.

Essential for correlating events across different devices. Absolutely.

Then there's SMMP simple network management protocol from monitoring device health and stats from a central network management station and MS. Understand the difference between SNMP traps which are unacknowledged alerts sent by the device, and informs which are acknowledged, making them more reliable but using more resources.

And NetFlow how does that fit in?

NetFlow is different from SNMP. SNMP tells you about the device itself, cpu load, memory usage, interface errors. NetFlow tells you about the traffic flowing through the device, who's talking to whom, how much data, what protocols invaluable for understanding traffic patterns, baselining and spotting anomalies.

Okay, monitoring is key. What about locking down the switch ports themselves, preventing random devices from plugging in.

That's switchport security critical for access layer switches where users connect. You can configure ports to only allow specific m mass addresses or a limited number of MC addresses.

As it learned which max are allowed.

You can configure them statically typing them in, or you can use stickymac. With stickymac, the switch learns the first a MAC address it sees on the port and automatically converts them into secure static entries in the running can fig.

Convenient, and you can limit the number, like if you have an IP phone and a PC connected to the same.

Port exactly, you'd set switchport port security maximum two in that case, one for the phone's data VLAN MAC, one for the PC's data vland MAC.

What happens if an unauthorized device plugs in depends on the violation mode.

You can figure the default is shut down. The port goes into an air disabled state and stops passing traffic needs manual intervention or automatic recovery to bring back up, or you can set it to restrict. It drops the bad traffic, sends an alert SNMP trap and counts the violation, or protect which just silently drops the bad traffic. No alert, no counter. Shutdown is usually recommended, and you.

Can configure or disabled recovery to automatically re enable the port after a while.

Yes, you can set timers for that other port security best practices shut down any unused ports administratively, don't leave them active, and assign them to an unused VLAN not VLAN one, and again change that native VLAN away from VLAN one.

Lots of layers to security. What about authenticating the administrators themselves instead of local passwords on every device.

Right For larger networks, managing local users on hundreds of devices is impractical. That's where centralized authentication comes in, using protocols like tech ass plus or Radius Rentoy. Triple A stands for Authentication, authorization and accounting. You set up triple A servers, often running tac ass plus serve, which is

Much more scalable and secure, central control way better for management, security, and auditing. Wow. Okay, so that really brings us full circle. We've gone from you know, basic hubs shouting everywhere, to intelligent switches directing traffic locally, routers navigating between networks.

Yeah, understanding the language they speak ip amris arp NAT.

How we organize them with vlands and connect those vlands with trunks and routing.

And finally the critical steps to actually secure these foundational pieces of the network.

It's been a real deep dive. The idea was to give you that shortcut, that solid understanding of the mechanics behind the scenes.

And hopefully knowing this stuff isn't just you know, interesting trivia. It really helps when things go wrong, when you need to figure out why you can't reach something, or when you're planning how to expand or secure your own network.

It empowers you, really gives you the foundational knowledge exactly. So as we wrap up, we've seen how these core networking ideas have evolved, but some fundamentals seem constant. Here's the thought to leave you with. With everything changing so fast, AI quantum competing on the horizon, what's one fundamental principle of network communication? Maybe something we touched on today that you think will always be critical no matter how the