Speaker 1: Imagine stepping behind the curtain of the digital world, not
Speaker 1: just you know, seeing the data flowing, but truly understanding
Speaker 1: the blueprints how networks are actually built, why they're designed
Speaker 1: that way, and how they connect well everything. Right today,
Speaker 1: we're doing just that, a deep dive into the let's say,
Speaker 1: art and science of enterprise network design.
Speaker 2: And we're using a pretty serious guide for this journey.
Speaker 2: It's an official certification resource, basically the playbook network architects use.
Speaker 1: Yeah, packed up the fundamentals, but also the really cutting
Speaker 1: edge stuff that makes today's networks teck exactly.
Speaker 2: So our mission here is to pull out the most
Speaker 2: vital bits of knowledge from all this material. We want
Speaker 2: you to walk away not just informed, but really getting
Speaker 2: what it takes to build a network that's stable, secure,
Speaker 2: and crucially scalable.
Speaker 1: Connecting the dots basically theory to practice. That's the plan. Okay,
Speaker 1: let's dive in, starting right at the foundation ip addressing.
Speaker 1: It's kind of a story of well scarcity leading eventually
Speaker 1: to abundance, it really is.
Speaker 2: It all kicked off with IPv four way back in nineteen.
Speaker 1: Eighty one ancient history and tech terms.
Speaker 2: Pretty much, but by the mid nineties people were already
Speaker 2: talking about apparent exhaustion running out of addresses. It seemed
Speaker 2: like a potential crisis.
Speaker 1: A major roadblock for the Internet's growth.
Speaker 2: Surely, absolutely, and that pressure it sparked some incredible ingenuity
Speaker 2: to cope with this dwindling supply. We got things like
Speaker 2: CIDR classless inner domain routing.
Speaker 1: Which made address allocation more.
Speaker 2: Flexible, right exactly, and NAT network address translation, letting many
Speaker 2: devices hide behind one public IP and of course RFC
Speaker 2: nineteen eighteen private address space.
Speaker 1: These weren't just technical tricks, they were fundamental design strategies totally.
Speaker 2: They had to be think about. ITA gave out the
Speaker 2: last main IPv four blocks in twenty eleven, am in
Speaker 2: in twenty fifteen, so even now, being smart about how
Speaker 2: you allocate those remaining IPv four addresses is still a
Speaker 2: critical design task thinking about that scarcity.
Speaker 1: Yeah, it was a really clever, maybe less obvious design
Speaker 1: workaround that came out of it, beyond just you know,
Speaker 1: the basic NAT definition.
Speaker 2: That's a good point. NAT often gets criticized right for
Speaker 2: breaking end to end stuff.
Speaker 1: Yeah, network peerists aren't always fans, but.
Speaker 2: Its ability to let companies merge even if they happened
Speaker 2: to be using the same private IP ranges internally. That
Speaker 2: was a lifesaver. Ah the overlapping networks problem precisely imagine
Speaker 2: trying to readdress thousands, maybe tens of thousands of devices
Speaker 2: during a merger, hugely expensive, risky nightmare. NAT provided a practical,
Speaker 2: if not perfectly elegant workaround. It kept businesses running and
Speaker 2: related to that efficiency, understanding subnetting and VLSU variable length
Speaker 2: subnet masking is just essential for designers.
Speaker 1: Not just chopping up networks.
Speaker 2: No, it's about precision. Assigning just enough addresses, like using
Speaker 2: a tiny thirty mask only two usable IPS for a
Speaker 2: point to point link between routers, minimal.
Speaker 1: Waste, or thirty two for a address.
Speaker 2: Exactly gives the router a stable identity that's always up,
Speaker 2: perfect for management using just one address. It's all about
Speaker 2: efficiency and enabling good route summarization later.
Speaker 1: Okay, addresses assigned, But for any of this to actually work,
Speaker 1: we need ways to translate names people use into these numbers,
Speaker 1: and for devices on the same network to find each
Speaker 1: other's hardware addresses.
Speaker 2: Absolutely essential. Plumbing DNS, the Domain Name system does the
Speaker 2: heavy lifting translating website names into IP addresses so routers
Speaker 2: know where to send stuff.
Speaker 1: The Internet's phone book basically.
Speaker 2: Kind of yeah, and then locally on the same network segment,
Speaker 2: you've got ARP Address resolution protocol that's mapping the known
Speaker 2: IP address to the physical MIS address needed for the
Speaker 2: final delivery.
Speaker 1: They seeing basic, but if they fail.
Speaker 2: Everything grinds to a halt. Their robust design is fundamental.
Speaker 1: Okay. So if IPv four was this story of scarcity,
Speaker 1: then IPv six that's about abundance, right, A huge lead
Speaker 1: from thirty two bids to one hundred and twenty eight bits.
Speaker 1: How does that change the design thinking.
Speaker 2: Oh, it's night and day. That vast address space, I mean,
Speaker 2: it's almost unfathomably large. Let's designers ditch many of the
Speaker 2: complex workarounds that IPv four scarcity forced on us. Like
Speaker 2: Matt potentially, yes, but beyond just more addresses, IPv six
Speaker 2: was designed with improvements. It has a simpler header, which
Speaker 2: routers can process faster less overhead. Right, security is built in.
Speaker 2: iPSC is an optional, it's a requirement, and path MTU
Speaker 2: discovery is standard, which eliminates the need for routers to
Speaker 2: fragment packets. That's a big deal for efficiency and reliability.
Speaker 1: So a cleaner, potentially faster, more secure foundation.
Speaker 2: That's the idea, and think about land design. The recommendation
Speaker 2: is to use a sixty four subnet for pretty much
Speaker 2: every land segment.
Speaker 1: Sixty four. That's billions upon billions of addresses for one
Speaker 1: network segment.
Speaker 2: Exactly more than you could ever possibly use. But it
Speaker 2: massively simplifies adjusts planning, and it enables things like SLA
Speaker 2: stateless Address autoconfiguration where devices can essentially give themselves a
Speaker 2: unique address without needing a DHCP server.
Speaker 1: That's a huge shift from meticulously planning every single IPv
Speaker 1: four subnet. And you mentioned a really key design practice
Speaker 1: for getting IPv six addresses to avoid future pain.
Speaker 2: Yes, this is crucial for long term stability, to avoid
Speaker 2: the massive renumbering projects that plagued IPv four networks when
Speaker 2: you changed ISPs. The strong recommendation is to get your
Speaker 2: IPv six address blocks directly from a regional Internet registry
Speaker 2: and RIR.
Speaker 1: Like Elion in North America or apn EK in Asia Pacific.
Speaker 2: Exactly, rather than just getting a block from your service provider.
Speaker 2: This makes your address based portable independent. It's a foundational
Speaker 2: decision for future proofing in.
Speaker 1: This structure from INA down to RIRs than ISPs. Then
Speaker 1: companies that helps keep the global Internet routing table manageable.
Speaker 2: It does. It allows for massive route summarization at the
Speaker 2: higher levels, even with the colossal number of potential networks.
Speaker 1: Okay, so we've got this amazing IPv six world, but
Speaker 1: let's face it, IPv four isn't going away overnight. How
Speaker 1: do network our caitects designed for this transition? How do
Speaker 1: they bridge that gap? Good question.
Speaker 2: The preferred method, the gold standard, really is dual stack,
Speaker 2: running both IPv four and IPv six protocols simultaneously on
Speaker 2: all your devices and network segments. Everything speaks both languages.
Speaker 1: So new stuff uses IPv six. Old stuff still works
Speaker 1: on IPv four pretty much.
Speaker 2: But sometimes a full dual stack rollout isn't immediately feasible,
Speaker 2: so designers have other tools, transitional tools.
Speaker 1: Tunneling is one option, like six to four or isotap.
Speaker 2: Right encapsulating IPv six packets inside ipp four packets to
Speaker 2: cross parts of the network that only understand IPv four.
Speaker 2: And then there are translation mechanisms.
Speaker 1: INDs sixty four and DNS sixty four exactly.
Speaker 2: They allow IPv six only clients to talk to IPv
Speaker 2: four only servers by translating addresses and protocols at the boundary.
Speaker 2: These are definitely migration tools, not usually the desired end state,
Speaker 2: but vital for the transition period.
Speaker 1: Okay, so addressing is clearly the beddrog. But once devices
Speaker 1: have addresses, how does the traffic figure out the best
Speaker 1: way to get from A to B? Especially in a big,
Speaker 1: complex enterprise network.
Speaker 2: Oh now we're talking about the network's GPS routing protocols
Speaker 2: guiding that traffic efficiently.
Speaker 1: And the first big design choice here seems to be
Speaker 1: this fundamental split distance vector versus link state protocols. What's
Speaker 1: the core difference.
Speaker 2: It's a huge difference, and it impacts scalability. How fast
Speaker 2: the network recovers from chain is convergent speed and just
Speaker 2: general complexity. Distance vector protocols like the classic RIP.
Speaker 1: Routing information protocol showing its age a bit.
Speaker 2: Now, Definitely they're simpler. Conceptually, Routers basically learn from their
Speaker 2: immediate neighbors, sharing their entire routing table periodically, routing by
Speaker 2: rumor some call it, which.
Speaker 1: Sounds like it could be slow. If something changes far away.
Speaker 2: It can be, and it can lead to more overhead
Speaker 2: sending those full tables around. Link state protocols like OSPF
Speaker 2: for ISIS work very differently. Also, each router builds a
Speaker 2: complete map, a topology of the entire network area it's in.
Speaker 2: They achieve this by flooding information about their own direct
Speaker 2: connections their.
Speaker 1: Link states, so everyone gets the same map.
Speaker 2: Within an area. Yes, and with that map, each router
Speaker 2: independently calculates the shortest path to every destination using an
Speaker 2: algorithm like diykstras.
Speaker 1: Which means faster convergence. Right yeah, if LINKO down, everyone recalculates.
Speaker 2: Quickly, much faster typically, and they only send updates when
Speaker 2: something actually changes, not the whole table periodically, so less
Speaker 2: routine overhead. The trade off is they generally need more
Speaker 2: memory and CPU power on the router and can be
Speaker 2: more complex to configure initially.
Speaker 1: And then there are hybrids like eig.
Speaker 2: RP right Enhanced Interior Gateway Routing Protocol. Cisco developed it
Speaker 2: to try and get the best of both worlds. Faster
Speaker 2: convergence than RIP, but maybe less complex than OSPF. In
Speaker 2: some ways, it uses aspects of both approaches.
Speaker 1: Okay, so you might have multiple protocols running, maybe some
Speaker 1: static routes someone configured manually. How does a router decide
Speaker 1: which route to actually believe or trust the most.
Speaker 2: That's where administrative distance or AD comes in. It's a
Speaker 2: critical concept for designers to master. Think of it as
Speaker 2: a trustworthiness score. Lower AD wins, So a.
Speaker 1: Route learned via EIGRP with its default eight of ninety.
Speaker 2: Is considered more trustworthy than an OSPF route default one
Speaker 2: ten or a RIP route.
Speaker 1: At one twenty than static routes.
Speaker 2: Default eighty of one, usually the most trusted because presumably
Speaker 2: the administrator put it there for a specific reason. Understanding
Speaker 2: AD is absolutely key to predicting and controlling how traffic
Speaker 2: actually flows, especially when you start mixing routing sources like
Speaker 2: redistributing routes between OSPF and EIGRP.
Speaker 1: Got it trustworthiness first, but then among routes from the
Speaker 1: same protocol, how does it pick the best path. It's
Speaker 1: got to be more than just counting routers like RIP does.
Speaker 2: Oh Absolutely, hopcount is a very crude metric. Modern protocols
Speaker 2: are much more sophisticated. OSPF uses cost, which by default
Speaker 2: is calculated based on the bandwidth of the link. Faster
Speaker 2: links get a lower cost, making them more.
Speaker 1: Profitable, so ten giglink beats a one giglink exactly.
Speaker 2: EIGRP is e and more complex. Its metric can factor
Speaker 2: in bandwidth, delay, interface load, and even reliability. This allows
Speaker 2: designers to really fine tune path selection based on what
Speaker 2: matters most for the application. Maybe lowest delay for voice,
Speaker 2: highest bandwidth for file.
Speaker 1: Transfers, and the big nightmare for routing loops, right traffic
Speaker 1: going round and round forever. How do designers prevent.
Speaker 2: That routing loops are definitely catastrophic? They can melt down
Speaker 2: a network segment. Fast protocols have built in loop prevention mechanisms,
Speaker 2: things like split horizon.
Speaker 1: Don't advertise a route back out the same way you learned.
Speaker 2: It precisely simple but effective. Poison reverse is a more
Speaker 2: aggressive version. Then there are mechanisms like maximum hopcounts RAP
Speaker 2: gives up after fifteen hops EGRP typically defaults to one
Speaker 2: hundred and fundamentally good route summarization is also a loop
Speaker 2: mitigation technique. How does summarization help with loops by hiding
Speaker 2: detailed topology information. If a specific link flaps up and
Speaker 2: down within a summarized block, the rest of the network
Speaker 2: doesn't necessarily need to know or react, using instability and
Speaker 2: preventing potential transient loops during convergence. It shrinks routing tables
Speaker 2: and limits the scope of changes, crucial for scalability.
Speaker 1: Makes sense, Let's dive into some of these protocols a
Speaker 1: bit more. EIGRP, what's a key design advantage it offers.
Speaker 2: Well beyond its fast convergence using the DAL algorithm. A
Speaker 2: really powerful and somewhat unique feature for designers is its
Speaker 2: ability to do unequal cost load sharing, Meaning most protocols,
Speaker 2: if they load balance, only do it across paths that
Speaker 2: have the exact same metric the same cost. EIGRP using
Speaker 2: the variance command, can be configured to send traffic across
Speaker 2: multiple paths, even if one path is say slightly slower
Speaker 2: or has a higher metric than the best path.
Speaker 1: So you can use links that might otherwise sit idle.
Speaker 2: Exactly, you can get better overall bandwidth utilization out of
Speaker 2: your network infrastructure. That's a significant practical advantage in many designs.
Speaker 1: Okay, what about IASSI Intermediate system to intermediate system sounds
Speaker 1: a bit old school OSI, but service love it. Why.
Speaker 2: It is based on OSI principles running directly over layer two,
Speaker 2: but It's incredibly robust and scalable for enterprise designers who
Speaker 2: might encounter it or consider it. Its inherent hierarchical nature
Speaker 2: is a plus for very large networks, but maybe more
Speaker 2: relevant today is its early adoption and strong support for
Speaker 2: things like wide metrics. Wide metrics using a larger field
Speaker 2: like twenty four bits for the metric calculation. This gives
Speaker 2: extremely fine grained control over path selection compared to say
Speaker 2: OSPF's default cost calculation. It's ideal for sophisticated traffic engineering
Speaker 2: where you need to precisely steer different types of traffic
Speaker 2: down specific paths based on very subtle differences.
Speaker 1: Interesting and OSPF open shortest path first probably the most
Speaker 1: common interior gateway protocol and enterprises key design points.
Speaker 2: It's the workhorse for sure. Uses Dykstra's SPF algorithm cost
Speaker 2: based on bandwidth. Designers need to understand the neighbor relationship requirements,
Speaker 2: things like matching area IDs timers MTU sizes must match
Speaker 2: for two routers to become neighbors.
Speaker 1: In the concept of areas area zero the backbone stub areas.
Speaker 2: Yes OSTF areas are fundamental to its scalability, breaking a
Speaker 2: large network into areas limits the scope of the SPF
Speaker 2: calculation and the amount of routing information routers need to handle.
Speaker 2: For designers, a common insight is that while the different
Speaker 2: area types STUB, totally stubby, NSSA offer flexibility, sometimes simpler
Speaker 2: is better, like.
Speaker 1: Using totally stubby areas for remote sites.
Speaker 2: Exactly, a totally stubby area gets only a default route
Speaker 2: from its area border router ABR. It hides all the
Speaker 2: complexity of the rest of the network. This dramatically simplifies
Speaker 2: the riting table on the remote routers, saving resources and
Speaker 2: often making troubleshooting easier. And OSPF three just adapts this
Speaker 2: whole structure for IPv six.
Speaker 1: Right. Finally, the Big one BGP Border Gateway Protocol. This
Speaker 1: connects the Internet right. Enterprises use it to talk to
Speaker 1: their ISPs.
Speaker 2: That's its main role. Yes, BGP is fundamentally different. It's
Speaker 2: a path vector protocol. It's less concerned with the shortest
Speaker 2: path and more concerned with the best policy compliant path
Speaker 2: between different organizations, different autonomous systems or asns.
Speaker 1: So it's about business relationships and routing policies as much
Speaker 1: as technical metrics.
Speaker 2: Very much so. Enterprises mainly deal with EBGP external BTP
Speaker 2: for AP peering with ISPs or other companies, and sometimes
Speaker 2: IBGP internal BGP to carry those external routes within their
Speaker 2: own network, and.
Speaker 1: That IBGP I hear it has a scaling challenge the
Speaker 1: full mesh requirement.
Speaker 2: It does by default, every IBGP router needs to peer
Speaker 2: directly with every other IBGP router in the same as
Speaker 2: in a large network. That's a lot of connections to manage.
Speaker 2: That's where design solutions like root reflectors come in.
Speaker 1: How do they help?
Speaker 2: A root reflector acts like a central point. Routers peer
Speaker 2: with the reflector and the reflector reflects the routes it
Speaker 2: learns to its other peers. This breaks the need for
Speaker 2: that full mesh, making IBGP much more scalable in large designs.
Speaker 2: Confederations are another more complex solution.
Speaker 1: And BGP paths selectction. It's complicated with all those attributes
Speaker 1: like aspath med local preference, which one do Enterprise designers
Speaker 1: often manipulate for practical outcomes.
Speaker 2: Local preference is a really common and powerful one. It's
Speaker 2: an attribute used inside your own autonomous system. You set
Speaker 2: a higher local preference value on the routes coming in
Speaker 2: from the ISP connection you prefer to use for outbound traffic.
Speaker 1: So you tell your internal routers, hey, use this Internet
Speaker 1: link first if it's available.
Speaker 2: Exactly. It's a primary tool for influencing your outbound traffic
Speaker 2: flow when you have multiple Internet connections. A very important
Speaker 2: for traffic engineering and ensuring you use your primary maybe
Speaker 2: higher bandwidth or lower cost link effectively.
Speaker 1: Okay, routing protocols chosen, paths selected, but architects need more
Speaker 1: granular control ye right and faster failure detection.
Speaker 2: Absolutely. That gets us into route manipulation redistribution. Taking routes
Speaker 2: from one protocol say OSPF and injecting them into another
Speaker 2: like BGP is powerful for connecting different parts of a network,
Speaker 2: but it's also risky. Also, you can easily create routing
Speaker 2: loops or suboptimal paths if you're not careful. So designers
Speaker 2: must use right filtering with things like route maps or
Speaker 2: distribute lists to control exactly which routes get redistributed and
Speaker 2: prevent feedback. It's essential and.
Speaker 1: Policy based routing PBR. That sounds like overriding the routing table,
Speaker 1: it is essentially.
Speaker 2: PBR lets you make routing decisions based on criteria other
Speaker 2: than just the destination address, like the source IP address
Speaker 2: or even application type, so a designer could say all
Speaker 2: traffic from the guests Wi Fi network, regardless of destination,
Speaker 2: should be sent out this specific maybe cheaper internet link.
Speaker 2: It allows for very granular policy enforcement.
Speaker 1: Very handy, and for failures, waiting for routing protocol timers
Speaker 1: could be slow.
Speaker 2: Way too slow sometimes, especially for real time applications. That's
Speaker 2: where BFD BI Directional Forwarding Detection is a game changer.
Speaker 2: It's a lightweight protocol designed purely for super fast failure detection,
Speaker 2: often in subsecond timeframes.
Speaker 1: Works across different links types.
Speaker 2: YEP, any media type, and it integrates with most routing
Speaker 2: protocols BGP, eigrp ospf isis. When BFD detects a link failure,
Speaker 2: it immediately tolls the routing protocol, which can then converge
Speaker 2: much much faster than waiting for its own HELLO timers
Speaker 2: or hold timers to expire. Critical design element for high availability.
Speaker 1: Okay, infrastructure addressed, traffic routed and controlled. But how do
Speaker 1: you actually watch all this? Keep tabs on performance health issues?
Speaker 2: Right? You need the eyes and ears network management and
Speaker 2: monitoring and the cornerstone protocol here is SNMP Simple Network Management.
Speaker 1: Protocol still simple after all these years.
Speaker 2: Oh well, the name's stuck. It's the industry's standard way
Speaker 2: for a network management system and NMS to query devices
Speaker 2: for information like CPU load, interface errors, or for devices
Speaker 2: to send alerts called traps.
Speaker 1: But security was an issue with early versions, wasn't.
Speaker 2: It huge issue? SNMPv one and v twoc used community strings,
Speaker 2: which were basically just plaintext passwords. Anyone sniffing the network
Speaker 2: could right them. That's why the critical design decision today
Speaker 2: is to use smmpv three. What is V three ad
Speaker 2: robust security? It provides authentication verifying who is asking and
Speaker 2: encryption scrambling the data. You can have different levels like
Speaker 2: off nopriv authentication no encryption or off PREV both. Deploying
Speaker 2: SNMPv three securely is non negotiable for modern network management
Speaker 2: plane design.
Speaker 1: Okay, so SNMP tells you device status, but what about
Speaker 1: the traffic itself? What's actually flowing across the network?
Speaker 2: For that level of detail, NetFlow is invaluable or its
Speaker 2: standardized version ipfax.
Speaker 1: How does it work?
Speaker 2: It collects metadata about IP flows. A flow is basically
Speaker 2: a sequence of packets going between the same source and
Speaker 2: destination ips and ports using the same protocol. NetFlow records
Speaker 2: details like how many packets, how many bytes, timestamps to
Speaker 2: s markings, so you.
Speaker 1: Can see who's talking to whom and how much data
Speaker 1: they're sending exactly.
Speaker 2: But the surprising insight for designers is how versatile this
Speaker 2: data is. Yes, it's great for troubleshoot why is the
Speaker 2: network slow, or capacity planning, or even billing. But it's
Speaker 2: also incredibly powerful for security spotting, denial of service attacks,
Speaker 2: or unusual traffic patterns that might indicate malware, and for
Speaker 2: application performance monitoring too.
Speaker 1: Though it's more than just counting bytes much more.
Speaker 2: It gives deep visibility with relatively low impact on the
Speaker 2: network devices themselves.
Speaker 1: What about other data to aid tools network teams rely
Speaker 1: on well.
Speaker 2: CDP Cisco Discovery Protocol is ubiquitous in Cisco environments. Layer
Speaker 2: two protocol lets Cisco devices automatically find their neighbors.
Speaker 1: Super useful for mapping things out quickly.
Speaker 2: Incredibly useful shows you the neighbor's device type, IP address,
Speaker 2: the specific port you're connected to. But and this is
Speaker 2: a key security design point, you absolutely must disable CDP
Speaker 2: on interfaces facing untrusted.
Speaker 1: Networks like the Internet connections exactly.
Speaker 2: You don't want to be broadcasting details about your internal
Speaker 2: devices to the outside world. And then there's cislog for
Speaker 2: logging events, right, it's the standard way for devices, routers, switches, firewalls,
Speaker 2: s first to send event messages to a central cislog server.
Speaker 2: Messages are categorized by a facility like OSPF for system
Speaker 2: and severity level from debugging up to emergency for designers,
Speaker 2: Ensuring consistent and useful logging is configured across the infrastructure
Speaker 2: is crucial for troubleshooting and auditing.
Speaker 1: Got it eyes and ears covered. Now let's get into
Speaker 1: actually building the structures land one and cloud design. Starting
Speaker 1: with a campus land that classic three layer model core distribution,
Speaker 1: access is that's still the way to go.
Speaker 2: It absolutely still is, maybe with some variations. That hierarchical
Speaker 2: model provides a really solid framework for designing scalable, resilient,
Speaker 2: and manageable campus networks.
Speaker 1: Can you break down the rolls quickly?
Speaker 2: Sure? Access layer is where your end users and devices connect,
Speaker 2: think switches and wiring closets, provides port security power over
Speaker 2: Ethernet for phones and aps. VLAN assignments not sare the edge. Right,
Speaker 2: Then the distribution layer aggregates the connections from multiple access switches.
Speaker 2: This is a really critical layer. It often handles routing
Speaker 2: between vlands, intervland routing, enforces access control policies, defines broadcast
Speaker 2: domain boundaries, and aggregates wiring closet uplinks. It's the policy
Speaker 2: and aggregation point and the core. The core is all
Speaker 2: about speed and reliability. Its job is simply to switch
Speaker 2: traffic between distribution blocks as fast as possible. No complex
Speaker 2: policies here, just high speed transport, usually a pair of powerful,
Speaker 2: redundant switches.
Speaker 1: And this separation helps with what troubleshooting, scaling both.
Speaker 2: If there's a problem in one access block, it's less
Speaker 2: likely to impact the whole network. Need to add more users,
Speaker 2: you add access switches and connect them to distribution. Need
Speaker 2: more capacity between buildings, you upgrade the core. It provides
Speaker 2: clear boundaries and predictable performance. For smaller sites, you might
Speaker 2: see a collapsed core where distribution and core functions are
Speaker 2: done on the same switches to save cost makes.
Speaker 1: Sense, and connecting these layers providing enough bandwidth and redundancy.
Speaker 1: What are the key tools?
Speaker 2: Ether channel is a big one. Bundling multiple physical links,
Speaker 2: say four to one gig links into one logical four
Speaker 2: gig link.
Speaker 1: Increases bandwidth and provides redundancy.
Speaker 2: Exactly if one physical link in the bundle fails, traffic
Speaker 2: automatically uses the remaining links huge for resilient uplinks between
Speaker 2: layers and at the access layer. POE power over Ethernet
Speaker 2: is just fundamental.
Speaker 1: Now powering phones, cameras, wireless aps directly through the network.
Speaker 2: Cable YEP simplifies wiring massively. You have different standards now, POE,
Speaker 2: POE plus eight, Cisco's UPOE offering even more power. Designers
Speaker 2: need to calculate power budgets for their access switches.
Speaker 1: Okay, Layer two loops are the enemy in switch networks.
Speaker 1: Spanding Tree Protocol STP prevents them, but it could be
Speaker 1: slow to converge right.
Speaker 2: The original STPA. Yes, that's why we have a whole
Speaker 2: toolkit of enhancements. Port Fast is essential on ports connecting
Speaker 2: to end devices like PCs or servers. It skips the
Speaker 2: sup listening learning phases, so the port comes up.
Speaker 1: Immediately, no waiting thirty fifty seconds for the port to work. Right.
Speaker 2: Then you have security features built around STP. Bpdu guard
Speaker 2: is critical. You put that on port fast enabled ports.
Speaker 2: If that port ever receives an BTDU packet, which it
Speaker 2: never should from an end device, it.
Speaker 1: Means someone plugged in a switch where they.
Speaker 2: Shouldn't have exactly a potential rogue switch trying to participate
Speaker 2: in STP. BBDU guard instantly shuts down the port to
Speaker 2: protect the network. Root guard is another one prevents a
Speaker 2: switch on a specific port from becoming the STP root bridge.
Speaker 2: Maintaining your design.
Speaker 1: Topology and UDLD for fiber.
Speaker 2: Links, Unidirectional link detection very important for fiber where you
Speaker 2: can have a situation where transmit works but receive fails
Speaker 2: or vice versa, STP might not detect that, potentially causing loops.
Speaker 2: UDLD specifically checks for this two way communication.
Speaker 1: Moving up the stack to layer three availability, keeping that
Speaker 1: default gateway always reachable. That's where fhrps come in.
Speaker 2: First hop redundancy protocols absolutely vital. The idea is to
Speaker 2: have two or more routers share a virtual IP address
Speaker 2: and MSS address, presenting themselves as a single logical default
Speaker 2: gateway to end devices.
Speaker 1: So if one router fails, the other takes over seamlessly.
Speaker 2: That's the goal. HSRP hot stand by Router Protocol is Cisco's.
Speaker 2: It has one active rider and one or more standby riders.
Speaker 2: VRRP Virtual Router Redundancy Protocol is the IETF standard. Similar
Speaker 2: concepts with the Master and Backups and GLBP Gateway load
Speaker 2: Balancing Protocol also ciscers. The unique thing here is that
Speaker 2: it allows all participating routers to be active simultaneously, load
Speaker 2: balancing traffic across them using different virtual MS addresses can
Speaker 2: provide better resource utilization than active standby models.
Speaker 1: And for even higher levels of switch redundancy.
Speaker 2: Technologies like Cisco's VSS Virtual Switching System or the newer
Speaker 2: Stackwise Virtual and Catalyst nine thousands are game changers. They
Speaker 2: allow you to merge two physical switches into a single
Speaker 2: logical switch from a management and control plane.
Speaker 1: Perspective, so they appears one big switch exactly.
Speaker 2: This eliminates the need for STP between them, allows for
Speaker 2: true active ether channel links to downstream devices, multi chassis
Speaker 2: ether channel, and simplifies configuration significantly, huge boost for core
Speaker 2: and distribution layer resilience in bandwidth.
Speaker 1: Okay, connectivity sorted, but what about application performance? Making sure
Speaker 1: voice and video calls don't break.
Speaker 2: Up quality of service QoS? It's not an optional extra anymore.
Speaker 2: It's a core design requirement, especially if you have limited
Speaker 2: bandwidth like over a whan link, or if you run
Speaker 2: real time applications.
Speaker 1: So how does it work? Generally?
Speaker 2: The dominant model today is diffserve differentiated services. You first
Speaker 2: classified traffic, identify what it is, voice, video, book data
Speaker 2: best effort. Then you mark it, usually by setting the
Speaker 2: DSCP value in the IP header like a priority tag
Speaker 2: sort of yeah. Then at congested points in the network,
Speaker 2: routers use that marking to apply policies. This usually involves queuing,
Speaker 2: putting different traffic types into different cueues. Voice goes in
Speaker 2: a high priority low length and CQ bulk data might
Speaker 2: go in a lower priority queue. Then scheduling mechanisms decide
Speaker 2: which queue gets serviced next, ensuring the important traffic gets.
Speaker 1: Through, so you guarantee performance for critical apps even when
Speaker 1: the network is busy.
Speaker 2: That's the objective. You might also use policing or shaping
Speaker 2: to rate limit less important traffic. It's a whole discipline,
Speaker 2: but essential for good user experience.
Speaker 1: Right shifting gears. Now to the wide area network the
Speaker 1: WAN connecting different sites maybe across the country or the globe.
Speaker 1: What drives.
Speaker 2: WAN design three main things, usually service level agreements SLAS
Speaker 2: What performance and availability does the business need? Cost WAN
Speaker 2: links can be expensive in usage. What applications need to
Speaker 2: run over the WAN? The overall goal is always to
Speaker 2: support the business meet application needs, stay secure and fit
Speaker 2: the budget.
Speaker 1: What are the traditional ways companies build WANs.
Speaker 2: Historically you had options like dedicated lease lines, frame relay
Speaker 2: ATM More commonly now you see layer two VPNs from
Speaker 2: service provider, which can give you Ethernet like connectivity between sites,
Speaker 2: but can be pricey. MPLS layer three VPNs are very
Speaker 2: popular ympls, cost effective, scalable. The provider handles the complex
Speaker 2: routing between sites using technologies like BGP and VRFs virtual
Speaker 2: routing and forwarding instances to keep customer traffic separate. Plus
Speaker 2: you can usually run QoS over mpls. Metro Ethernet is
Speaker 2: also big for high speed connectivity within a city or region,
Speaker 2: and some large enterprises might even use DWDM or at
Speaker 2: least dark fiber for ultimate control and bandwidth, though that
Speaker 2: requires designing external redundancy yourself.
Speaker 1: And nowadays wireless is a bigger player.
Speaker 2: Too, Definitely four G and increasingly five GLTE are becoming
Speaker 2: viable not just as backup links, but sometimes as primary
Speaker 2: WAN connectivity for smaller branches or retail locations, offering flexibility
Speaker 2: and rapid deployment, Which brings us.
Speaker 1: To the really big shift ST one Software defined one.
Speaker 1: What's the hype? How does it change the game for
Speaker 1: WAND designers?
Speaker 2: SD one is genuinely transformative. It's an overlay architecture that
Speaker 2: decouples the WAN services routing security policy from the underlying
Speaker 2: physical transport links.
Speaker 1: Meaning you can use any connection MPLS, Internet, broadband four
Speaker 1: G exactly.
Speaker 2: That's transport independence. Designers can mix and match links based
Speaker 2: on cost, performance and reliability needs for different applications. SD
Speaker 2: one provides centralized management and orchestration, zero touch provisioning for
Speaker 2: new sites, integrated security features, and amazing visibility into application performance.
Speaker 1: So instead of configuring each router individually.
Speaker 2: You define policy centrally. Like salesforce, traffic prefers the MPLS
Speaker 2: link but can fail over to broadband or guess Wi Fi.
Speaker 2: Traffic goes direct to Internet, and the SD one controller
Speaker 2: pushes that configuration out and manages the traffic flow automatically
Speaker 2: across the entire fabric. It simplifies operations massively and optimizes performance.
Speaker 1: How does this software defined approach actually work architecturally? What
Speaker 1: are the pieces?
Speaker 2: It's typically broken into logical planes. There's the orchestration plane
Speaker 2: often called v bond and Cisco's Viptella solution, which authenticates
Speaker 2: new SD one routers and tells them how to find
Speaker 2: their controller.
Speaker 1: Good onboarding part right.
Speaker 2: Then the management plane vmanage is your single pane of
Speaker 2: glass for configuration, monitoring, troubleshooting, analytics. The control plane V
Speaker 2: smart is the brains. It learns the topology, distributes routing
Speaker 2: and policy information between the SD one routers using a
Speaker 2: protocol like OMP Overlay Management Protocol, so.
Speaker 1: V smart tells everyone how to reach everyone else correct.
Speaker 2: And finally, the data plane consists of the SD one
Speaker 2: routers themselves vh or Cisco iOS S two one routers,
Speaker 2: which actually builds secure tunnels between sites and ford user
Speaker 2: traffic based on the decisions made by the.
Speaker 1: V smart controller and bringing up new sites is easier.
Speaker 2: Potentially much easier with zero touch provisioning ZTP. Ship a
Speaker 2: router to a site, plug it in, It connects to
Speaker 2: the orchestration plane, gets its configuration and joins the fabric
Speaker 2: automatically huge time saver and.
Speaker 1: With cloud adoption booming, what does SDWE fit in? Does
Speaker 1: it help connect to AWS or Azure?
Speaker 2: Absolutely? Most STWE solutions have specific cloud on ramp features.
Speaker 2: These are designed to provide optimized, secure, and automated connectivity
Speaker 2: directly into public cloud environments infrastructure as a service like AWS, Azure,
Speaker 2: Google Cloud.
Speaker 1: So extending the st one fabric into.
Speaker 2: The cloud essentially yes, making the cloud, VPC or VNA
Speaker 2: just another site on your when. They also often have
Speaker 2: features to optimize performance for software as a service SAUCE
Speaker 2: applications like Microsoft three sixty five or Salesforce. By intelligently
Speaker 2: routing traffic directly to the closest SAUCE entry point, it
Speaker 2: helps integrate the clouds seamlessly into the overall enterprise network design,
Speaker 2: whether you're using public, private, or hybrid cloud models.
Speaker 1: Okay, that covers a massive amount of ground on building networks. Yeah,
Speaker 1: but the way we manage and interact with these networks
Speaker 1: is changing rapidly to which leads to our final segment,
Speaker 1: the future automation and programmability. We've definitely moved beyond just
Speaker 1: typing commands into a CLI one by.
Speaker 2: One right, oh massively. The shift towards automation is probably
Speaker 2: the single biggest trend in network operations and design right now,
Speaker 2: and it's all enabled by network APIs and new protocols
Speaker 2: like rest APIs.
Speaker 1: We hear about those everywhere right.
Speaker 2: Rest representational state transfer using standard HTTP methods like get, post,
Speaker 2: put delete. The cred operations provides a relatively simple, web
Speaker 2: friendly way to interact with network devices programmatically. Many modern
Speaker 2: devices offer rest APIs for configuration and monitoring.
Speaker 1: But then there's netcom that sounds more network specific.
Speaker 2: It is netcon Network Configuration Protocol is an IETF standard
Speaker 2: specifically designed for network device management. It's more robust and
Speaker 2: structured than just slinging CLI commands via SSH or using
Speaker 2: basic REST.
Speaker 1: How is it better?
Speaker 2: It uses XML encoding over SSH, providing clear, standardized operations
Speaker 2: like get config, edit, canfig commit. Crucially, it understands the
Speaker 2: concept of different configuration data stores. The running canfig a
Speaker 2: candidate config you can build and validate before applying, and
Speaker 2: the startup CANFIG. This allows for more reliable transactional configuration changes.
Speaker 2: You can make a bunch of changes, validate them, and
Speaker 2: then commit them all at once, much.
Speaker 1: Safer for automation, less chance of leaving a device half
Speaker 1: configured exactly.
Speaker 2: And restcon is basically a way to get rest like convenience,
Speaker 2: but using the structured data models defined by YANG which
Speaker 2: we'll get to and gRPC from Google is another option
Speaker 2: often used for high performance streaming telemetry.
Speaker 1: Okay, so those are the protocols for talking to the devices,
Speaker 1: but the automation tools need a structured way to understand
Speaker 1: the data itself, the configuration options, the status information precisely.
Speaker 2: That's where data models and formats are key. The big
Speaker 2: one here is YANG, yet another next generation. It's a
Speaker 2: data modeling language.
Speaker 1: So it defines the structure.
Speaker 2: Yes, it defines the structure, syntax, and semantics of network
Speaker 2: configuration and state data in a way that's independent of
Speaker 2: any specific device, vendor or protocol. Think of it as
Speaker 2: a standardized blueprint for what you can configure or monitor
Speaker 2: on a device. Automation tools can read these young models
Speaker 2: to understand exactly how to interact with the device via
Speaker 2: netcon or rest coon.
Speaker 1: And the actual data formats used Jason and XML.
Speaker 2: Those are the main ones. JSON Jobscript Object notation is
Speaker 2: very popular, lightweight, human readable, easy for machines to parse
Speaker 2: often used with rest con XML extensible markup language is
Speaker 2: more verbose but very structured. The standard format used by NETCN.
Speaker 1: Got it, and this leads to something called model driven
Speaker 1: te lemetry. Sounds futuristic.
Speaker 2: It's the future of network monitoring happening now. Traditional monitoring
Speaker 2: often uses S and m P polling. The NMS asks
Speaker 2: the device for data every few minutes. Poll model model
Speaker 2: driven to Lemontry flips that it's a push model. The
Speaker 2: network device streams data continuously or whenever something changes to
Speaker 2: subscribers like a monitoring system using those YANG models exactly.
Speaker 2: It leverages standard YANG models to define what data to
Speaker 2: stream and often uses efficient transports like gRPC or net conodifications.
Speaker 2: You can subscribe to specific data points like interface counters,
Speaker 2: CPU utilization, routing, neighbor states.
Speaker 1: And get updates in near real time.
Speaker 2: Potentially yes, you can configure periodic streaming every few seconds
Speaker 2: or on change streaming only when a value changes. This
Speaker 2: gives much more granular timely visibility into network health and
Speaker 2: performance compared to slower polling cycles. It's fantastic for proactive troubleshooting,
Speaker 2: capacity planning, and even feeding automation systems to react instantly
Speaker 2: to network events.
Speaker 1: Wow, that really changes the monitoring game.
Speaker 2: It really does much more efficient and insightful.
Speaker 1: Okay, incredible. We have covered so much ground from the
Speaker 1: absolute basics of IP, addressing that journey from scarcity with
Speaker 1: IPv four to the vastness of IPv six.
Speaker 2: Right, and the design implications of that shift, through.
Speaker 1: The intricate world of routing protocols, choosing between distance vector
Speaker 1: link state, path vector, understanding metrics and ad all.
Speaker 2: About guiding that traffic and in elligently and reliably.
Speaker 1: To keeping watch with network management tools like SNNP, NetFlow, cyslog.
Speaker 2: The essential eyes and ears.
Speaker 1: Then diving deep into building resilient lands with hierarchical design
Speaker 1: STP enhancements fhrps and the modern wan with mpls and
Speaker 1: especially the rise of SD one.
Speaker 2: And connecting that all seamlessly to the cloud.
Speaker 1: And finally looking at the future with automation APIs like
Speaker 1: net COF and rest cond data models like YANG, and
Speaker 1: that real time view from model driven telemetry. You should
Speaker 1: now have a much much deeper appreciation for all the
Speaker 1: layers of thought and design that make our digital world function.
Speaker 2: It's a constantly moving target too. The beauty of network
Speaker 2: design is that it never stands still. Every single concept
Speaker 2: we touched on is evolving, being refined. It keeps network
Speaker 2: architects on their toes definitely.
Speaker 1: We've seen how decades of problem solving shaped things, tackling
Speaker 1: IPv for limits, building routing protocols moving towards this software
Speaker 1: defined automated future. So as these technologies keep racing forward,
Speaker 1: here's something to think about. We talked about core principles scalability,
Speaker 1: high availability, security. How much further can these principles be pushed?
Speaker 1: How might they be fundamentally redefined by the automation, the programmability,
Speaker 1: the AI even that's starting to permeate network design. What
Speaker 1: new challenges and what incredible new opportunities will emerge as
Speaker 1: a network itself becomes even more intelligent and adaptable