# Network Admin Journey — full content > Connecting Networks Innovatively. Source: https://roadtoneteng.com/ --- # «Quando la diretta TV diventa caos: cosa succede dietro le telecamere e perché la rete deve funzionare sempre» URL: https://roadtoneteng.com/quando-la-diretta-tv-diventa-caos-cosa-succede-dietro-le-telecamere-e-perche-la-rete-deve-funzionare-sempre/ Updated: 2026-10-20 --- # The Road from Network Administrator to Network Engineer: A Practical Career Roadmap URL: https://roadtoneteng.com/road-from-network-admin-to-network-engineer/ Updated: 2026-10-14 If you are a network administrator, you already have something many aspiring engineers would love to have: real production experience. You have reset ports at 7 a.m. before the office fills up, chased down a rogue DHCP server, and learned the hard way why nobody touches the core switch on a Friday afternoon. The jump to network engineer is not about starting over. It is about turning that operational experience into design thinking, deeper protocol knowledge and the confidence to own the network instead of just keeping it running. This roadmap walks you through exactly how to do that, step by step. ## Network administrator vs. network engineer: what actually changes Job titles are messy. In a small business, the "IT guy" may configure the firewall, design the VLAN layout, and reset passwords in the same morning. In a large enterprise, an administrator may never touch a routing protocol configuration at all. Still, there is a meaningful difference in focus between the two roles, and understanding it tells you what you need to learn. An administrator primarily operates the network. The work is reactive and procedural: moves, adds and changes, user tickets, patching, backups, monitoring alerts and following runbooks someone else wrote. An engineer primarily designs and improves the network. The work is proactive and analytical: deciding how the network should be built, why, and what it will need in two years. Area | Network administrator | Network engineer | Main focus | Keep the network running day to day | Design, build and evolve the network | Typical tasks | Port changes, user issues, backups, firmware updates | Architecture, addressing plans, routing design, capacity planning | Troubleshooting | Follows known fixes and escalates hard problems | Owns root cause analysis across layers and vendors | Change scope | Small, low-risk, often pre-approved changes | Large changes, migrations, rollback planning | Documentation | Updates existing records | Writes designs, standards and runbooks | Communication | Mostly with users and the service desk | With management, vendors, security and application teams | Notice that none of these differences is about intelligence or talent. They are about scope, depth and ownership. That is good news, because all three can be built deliberately. ## Assess your starting point honestly Before you plan the route, figure out where you are on the map. Many admins either underestimate themselves ("I just do tickets") or overestimate their depth ("I configure VLANs every week, so I know switching"). Both slow you down. Take an inventory of what you can do without looking anything up. A useful self-check is to ask whether you could explain each of these topics to a junior colleague on a whiteboard: - How a host decides whether a destination is local or remote, and what ARP does next. - How to subnet a /24 into smaller networks and calculate network, broadcast and host ranges in your head. - What happens to a frame as it crosses an 802.1Q trunk, and what the native VLAN is for. - Why Spanning Tree blocks certain ports and how the root bridge is elected. - How a router chooses between a static route, an OSPF route and a connected route to the same prefix. - What NAT, DHCP relay and DNS are doing during a typical user's first minute on the network. - How a stateful firewall decides whether return traffic is allowed. Mark each one as "solid", "shaky" or "no idea". The shaky items are your highest-value study targets, because they are the gaps you are most likely to be exposed on in an interview or, worse, during an outage. Pro tip: Keep this self-assessment in a simple document and revisit it every month. Seeing items move from "no idea" to "solid" is a powerful motivator during the long middle stretch of any career change. ## The core technical skills you need to master Network engineering rests on a fairly stable foundation. Vendors, platforms and buzzwords change, but the fundamentals have barely moved in decades. Invest here first. ### Addressing and subnetting Subnetting is the multiplication table of networking. Engineers design addressing plans, summarize routes, write ACLs and size DHCP scopes, and every one of those tasks depends on fluent subnetting. You should be able to work out the network, broadcast address and usable range for any IPv4 prefix quickly and accurately. If that is not true yet, work through our step-by-step subnetting guide until it is automatic. Add IPv6 addressing next; it is no longer optional for anyone designing networks. ### Switching and Layer 2 design Most admins configure access ports. Engineers decide how many VLANs exist, what each one is for, where Layer 3 boundaries sit, and how loops are prevented. You need a working understanding of VLANs and 802.1Q trunking, Rapid Spanning Tree, EtherChannel with LACP, first-hop redundancy, and Layer 2 security features such as DHCP snooping and dynamic ARP inspection. Our article on VLAN design, trunking and inter-VLAN routing is a good place to fill gaps. ### Routing Routing is where many admins hit a wall, because small networks often run on a single default route. Learn how the routing table is built, what administrative distance and metric mean, and how longest-prefix matching works. Then go deep on one interior gateway protocol, which in most enterprise environments means OSPF. Once you are comfortable with OSPF areas, neighbor states and LSA types, learn enough BGP to understand how your organization connects to its internet providers and cloud platforms. ### Security fundamentals Engineers are expected to build networks that are secure by design. That means understanding segmentation, ACLs, stateful firewall policy, VPN technologies such as IPsec, AAA with RADIUS or TACACS+, and management-plane hardening. You do not have to become a security specialist, but you must be able to have an informed conversation with one. ### Wireless and services Wireless is often the network users actually experience, so learn the basics of RF, channel planning and controller-based architectures. Round out your knowledge with the services that glue everything together: DHCP, DNS, NTP, SNMP, syslog and NetFlow. ## A phased roadmap from admin to engineer Trying to learn everything at once is the fastest way to burn out. Break the journey into phases, each with a clear goal and a clear signal that you are ready to move on. The timelines below are rough guides for someone studying consistently alongside a full-time job; adjust them to your situation. ### Phase 1: Solidify the fundamentals (roughly 3–6 months) Your goal is to remove every "shaky" item from your self-assessment. Study for a foundational certification such as the CCNA, because a structured blueprint keeps you honest about topics you would otherwise skip. Build a lab, even a virtual one, and configure every technology you read about. If you want a structured schedule, our 90-day CCNA study plan breaks the blueprint into weekly goals. You are ready to move on when you can build a small multi-VLAN, multi-router network from a blank configuration, with OSPF, DHCP, NAT and basic ACLs, and troubleshoot it when something breaks. ### Phase 2: Take on engineering work where you are (roughly 6–12 months) This phase matters more than any certificate. Start acting like an engineer in your current job. Volunteer to write the change plan for the next switch replacement. Offer to document the current topology and addressing. Propose a fix for the recurring problem everyone has learned to live with. Ask to shadow the senior engineer during a maintenance window. You are ready to move on when you have two or three small projects you designed or led, with documentation you can describe in an interview. ### Phase 3: Specialize and deepen (ongoing) Once your fundamentals are strong, choose a direction: enterprise routing and switching, security, wireless, data center, cloud networking, or service provider. Work toward a professional-level certification or equivalent depth in that area, and begin automating your own workflows. You are ready to move on when colleagues start bringing their hard problems to you rather than the other way around. ### Phase 4: Make the move With fundamentals, real project experience and a specialization underway, you are a credible engineering candidate, either through an internal promotion or an external role. We cover how to approach that step later in this article. ## Build hands-on experience on purpose Reading about OSPF is not the same as watching an adjacency get stuck in EXSTART because of an MTU mismatch. Hands-on experience is what turns knowledge into judgment, and engineering is mostly judgment. ### Your home lab A lab is your safe place to break things. Virtual platforms such as Cisco Packet Tracer, GNS3, EVE-NG and Containerlab let you build complex topologies on a laptop or a small server, while a few used switches and routers give you physical experience with cabling, console access and real hardware behavior. Our guide on building a home network lab on any budget compares the options in detail. Do not just follow lab guides step by step. Once a lab works, break it deliberately: shut an interface, change a VLAN on one end of a trunk, mismatch an OSPF timer, remove a route. Then fix it using only show commands and logic. That exercise mirrors the real job far more closely than any tutorial. ### Turn your current job into a training ground Your production network is the best lab you will ever have access to, as long as you respect change control. Read the running configurations of your core devices line by line and make sure you understand every command. Look at the routing tables. Map the spanning tree topology and check whether the root bridge is where it should be. Review the firewall rule base and ask why each rule exists. Every question you answer this way builds the kind of context interviewers love to hear about. Watch out: Never use production as a place to test ideas. Read, observe and document freely, but make changes only through your organization's change process with a tested rollback plan. Engineers are trusted precisely because they do not cause outages through curiosity. ## Certifications: which ones matter and when Certifications are not a substitute for experience, but they do three useful things: they give you a structured curriculum, they get your resume past automated filters, and they signal commitment to hiring managers. Choose them strategically rather than collecting them. Stage | Common options | Why it helps | Foundation | CompTIA Network+, Cisco CCNA | Proves core knowledge; CCNA is widely recognized and hands-on focused | Vendor alternatives | Juniper JNCIA-Junos, Aruba/HPE or Fortinet entry-level certifications | Useful if your employer or local market runs that vendor | Professional | Cisco CCNP Enterprise, Juniper JNCIP tracks, equivalent vendor-professional levels | Shows design and advanced routing and switching depth | Specialization | Security, wireless, cloud networking or automation tracks | Supports a chosen direction and differentiates you | Expert | CCIE and similar expert-level programs | Long-term goal for deep specialists; not required for most engineering roles | For most admins, the CCNA is the right first step, even if your network is not all Cisco. The concepts transfer to any vendor, and the exam covers the exact fundamentals that separate engineers from operators. After that, let your target job postings guide you. If the roles you want consistently ask for a particular professional-level certification or cloud credential, that is your next target. Note: Certification blueprints, prices and exam formats change over time. Always check the vendor's official exam page for the current topics before you start studying. If you want accountability and a mentor reviewing your lab work, our 1:1 CCNA Mentorship Program pairs a structured eight-week plan with personal guidance. ## Add automation to your toolkit A decade ago, automation was a niche interest. Today, it is a normal expectation in many engineering job descriptions. The good news is that you do not need to become a software developer. You need to be able to remove repetitive, error-prone manual work. A practical learning order looks like this: - Git. Store your configurations, scripts and documentation in version control. It teaches you change tracking and collaboration habits that apply everywhere. - Python basics. Variables, loops, functions, reading files and working with dictionaries and lists. That is enough to start. - Structured data. Learn to read and write JSON and YAML, because APIs and automation tools speak them. - Device interaction. Use a library such as Netmiko to log in to devices, run show commands and push simple configuration changes. - Configuration management. Learn Ansible to describe desired configuration in playbooks and apply it consistently across many devices. - APIs. Understand REST, HTTP methods and authentication so you can work with controllers, cloud platforms and modern network operating systems. Start with a problem you actually have. A script that backs up every switch configuration nightly, or that audits which access ports are missing BPDU Guard, is more valuable to your learning and your employer than any toy example. Our guide to network automation with Python and Ansible walks through these tools with real examples. ## The non-technical skills that make you an engineer Ask experienced engineers what separates a senior colleague from a junior one, and they rarely mention a protocol. They talk about judgment, communication and ownership. These skills are trainable, and admins who work on them early stand out quickly. ### Documentation and design writing Engineers produce designs that others implement and maintain. Practice writing short design documents: the problem, the requirements, the options you considered, the option you chose and why, the implementation steps, and the rollback plan. Keep diagrams, IP address plans and runbooks current. Strong documentation habits make you visibly more valuable, because they let other people support what you build. ### Change management and risk thinking An engineer's job is not to make changes; it is to make changes safely. For every change, ask: what can go wrong, how will I know, how do I roll back, and who is affected? Learning to frame work this way earns trust from managers, which in turn earns you bigger projects. ### Communication with non-network people You will explain technical constraints to managers, negotiate maintenance windows with application owners, and push back on vendors. Practice describing a problem in terms of business impact rather than protocol detail. "Users at the branch lose access to the ERP system for about thirty seconds whenever the primary link flaps" lands far better than "OSPF reconverges slowly over the WAN." ### Structured troubleshooting Admins often troubleshoot by intuition and memory. Engineers use a method: define the problem precisely, gather facts, form hypotheses, test them one at a time, and document the result. A repeatable approach is what lets you solve problems you have never seen before. Write your method down, use it on every ticket, and refine it after each incident review. ## Making the move: internal promotion or a new job When your skills and experience are ready, you have two main paths. Neither is better in general; the right choice depends on your employer. ### Growing into the role internally Internal moves are often the smoothest, because your manager already knows your work. Make your ambitions explicit; do not assume anyone has noticed. Ask your manager what an engineer at your organization is expected to do, then build a plan together to close the gaps. Keep a running list of projects you contributed to and the outcomes they produced. When review time arrives, you will have concrete evidence rather than a vague request. ### Moving to a new employer If there is no engineering path where you are, an external move may be necessary. Rewrite your resume around outcomes and projects rather than duties. Instead of "Responsible for switch configuration," write something like "Designed and implemented a new VLAN segmentation plan for 300 users, separating voice, data, guest and management traffic." Be ready to explain every project in depth, because engineering interviews tend to probe the why behind each decision. ### Preparing for engineering interviews - Whiteboard fundamentals. Expect to walk through what happens when a user opens a web page, or to subnet a network on the spot. - Troubleshooting scenarios. Practice talking through your method out loud: what you would check first, and why. - Design questions. Be ready to sketch a small office or branch network and justify your choices. - Behavioral questions. Prepare stories about outages you handled, mistakes you made and what you changed afterward. Pro tip: Saying "I don't know, but here is how I would find out" is a strong answer in an engineering interview. Interviewers are testing your reasoning, and an honest, structured approach beats a confident guess. ## Key takeaways - The admin-to-engineer move is about scope, depth and ownership, not starting over. Your operational experience is an asset. - Start with an honest self-assessment and target your shaky fundamentals first: subnetting, switching, routing and security. - Follow a phased plan: solidify fundamentals, take on engineering work in your current role, specialize, then make the move. - Build a lab and break things on purpose; treat production as a place to observe and learn, and change it only through proper change control. - Use certifications strategically. The CCNA is a strong first step, and target job postings should guide what comes next. - Learn practical automation, starting with Git and Python and moving to Netmiko, Ansible and APIs. - Documentation, change management, communication and structured troubleshooting are what make people trust you with engineering work. Every network engineer started somewhere, and many of the best started exactly where you are now: in the trenches, keeping the network alive. If you want a personalized plan, a review of your current skills or a structured path to your first certification, explore our interactive learning roadmap or get in touch to talk through mentoring options. ## FAQ Q: What is the main difference between a network administrator and a network engineer? A: A network administrator mostly operates and maintains an existing network: moves, adds and changes, user issues, backups and monitoring. A network engineer designs, builds and improves the network: choosing architectures, planning addressing and routing, evaluating hardware, and owning larger changes and projects. In smaller companies one person often does both. Q: How long does it take to go from network admin to network engineer? A: It varies a lot with your starting point, the time you can invest and the opportunities at your employer. Many admins who already work hands-on with switches and routers make the move within one to three years by studying consistently, building a lab and deliberately taking on design and project work. Q: Do I need a CCNA to become a network engineer? A: No certification is strictly required, but the CCNA is one of the most widely recognized proofs of networking fundamentals and is frequently listed in job postings. It also forces you to learn topics that many admins skip, such as subnetting fluency, STP behavior and OSPF. Pair it with real experience for the best results. Q: Should network engineers learn programming? A: Yes, at least to a practical level. You do not need to be a software developer, but basic Python, working with APIs and JSON, version control with Git and a tool such as Ansible will let you automate repetitive work, reduce configuration errors and stand out in interviews. Q: Can I become a network engineer without a degree? A: Many network engineers do not have a computing degree. Employers typically care more about demonstrable skills, relevant certifications, project experience and how clearly you can explain your design and troubleshooting decisions. Some organizations do still filter on degrees, so check postings in your market. --- # Subnetting Made Simple: A Step-by-Step Guide to IPv4 and CIDR URL: https://roadtoneteng.com/subnetting-made-simple/ Updated: 2026-10-14 Subnetting has a reputation as the part of networking that separates people who "get it" from people who do not. The truth is less dramatic. Subnetting is a small set of rules applied consistently, and once you see the pattern behind them you can solve most problems in your head in seconds. This guide takes you from IPv4 basics to CIDR, the block size method, fully worked examples, VLSM design and route summarization, with a reference table you can keep next to your keyboard. ## Why subnetting still matters It is tempting to think a calculator makes subnetting knowledge unnecessary. In practice, you use subnetting constantly, often without noticing. Every time you size a DHCP scope, write an access list, choose an address for a new VLAN interface, read a routing table or troubleshoot why two hosts cannot reach each other, you are applying subnetting logic. Fluent subnetting gives you three practical advantages: - Faster troubleshooting. You can spot a wrong mask or a gateway outside the host's subnet at a glance. - Better design. You can build addressing plans that are efficient, easy to summarize and easy to understand. - Exam and interview confidence. Subnetting appears in nearly every networking certification and technical interview, and it is usually timed. Calculators are great for checking your work, and we have one on our network tools page. But the goal of this guide is to make you independent of them. ## IPv4 address basics in five minutes An IPv4 address is a 32-bit number. For human convenience, we split it into four 8-bit groups called octets and write each as a decimal number from 0 to 255, separated by dots. The address 192.168.10.25 is really this binary value: Octet | Decimal | Binary | 1st | 192 | 11000000 | 2nd | 168 | 10101000 | 3rd | 10 | 00001010 | 4th | 25 | 00011001 | Each bit position in an octet has a fixed value. From left to right they are 128, 64, 32, 16, 8, 4, 2 and 1. To convert binary to decimal, add the values of the bits that are set to 1. For 00011001, that is 16 + 8 + 1 = 25. Memorize those eight values; everything else in subnetting builds on them. ### Network portion and host portion Every IPv4 address is divided into two parts. The network portion identifies which subnet the address belongs to, and the host portion identifies the individual interface within that subnet. The subnet mask tells you where the dividing line sits. A subnet mask is also 32 bits long. It is a continuous run of 1s followed by a continuous run of 0s. The 1s mark the network bits and the 0s mark the host bits. The mask 255.255.255.0 is 24 ones followed by 8 zeros, so the first three octets are the network and the last octet is the host portion. ### Network, broadcast and usable hosts Within any traditional subnet, two addresses are special: - The network address has all host bits set to 0. It identifies the subnet itself. - The broadcast address has all host bits set to 1. Packets sent to it reach every host in the subnet. Everything in between is usable for hosts. That gives us the two formulas you will use constantly: - Total addresses in a subnet = 2h, where h is the number of host bits. - Usable hosts = 2h − 2. When you borrow bits from the host portion to create subnets, the number of subnets you get is 2s, where s is the number of borrowed bits. ## CIDR notation and private address space Originally, IPv4 used fixed classes. Class A networks had an 8-bit network portion, Class B had 16 bits and Class C had 24 bits. That was simple but wasteful: an organization needing 300 addresses was too big for a Class C and wasted most of a Class B. Classless Inter-Domain Routing (CIDR), introduced in RFC 1519 and updated by RFC 4632, removed the fixed boundaries. A network can now have any prefix length from /0 to /32. CIDR notation writes the prefix length after a slash, counting the 1 bits in the mask. These two forms mean exactly the same thing: - 192.168.10.0 with mask 255.255.255.192 - 192.168.10.0/26 Because 255.255.255.192 contains 26 leading ones (8 + 8 + 8 + 2), the prefix is /26. You will see both forms in the real world. Cisco IOS interface configuration uses dotted-decimal masks, while routing tables, documentation and most other platforms favor CIDR. ### Address ranges you should recognize Range | Purpose | Reference | 10.0.0.0/8 | Private addressing | RFC 1918 | 172.16.0.0/12 | Private addressing (172.16.0.0 to 172.31.255.255) | RFC 1918 | 192.168.0.0/16 | Private addressing | RFC 1918 | 100.64.0.0/10 | Shared address space for carrier-grade NAT | RFC 6598 | 169.254.0.0/16 | Link-local (automatic addressing when DHCP fails) | RFC 3927 | 127.0.0.0/8 | Loopback | RFC 1122 | Pro tip: If a Windows or macOS client shows a 169.254.x.x address, it did not receive a DHCP lease. Check the switch port VLAN, the DHCP relay (ip helper-address) and the DHCP server's scope before anything else. ## Subnet reference table: /24 to /30 Most day-to-day subnetting in enterprise networks happens in the last octet. This table covers the prefixes you will meet most often. The wildcard mask column is useful for ACLs and OSPF network statements; it is simply the subnet mask inverted. Prefix | Subnet mask | Wildcard mask | Block size | Total addresses | Usable hosts | Subnets per /24 | /24 | 255.255.255.0 | 0.0.0.255 | 256 | 256 | 254 | 1 | /25 | 255.255.255.128 | 0.0.0.127 | 128 | 128 | 126 | 2 | /26 | 255.255.255.192 | 0.0.0.63 | 64 | 64 | 62 | 4 | /27 | 255.255.255.224 | 0.0.0.31 | 32 | 32 | 30 | 8 | /28 | 255.255.255.240 | 0.0.0.15 | 16 | 16 | 14 | 16 | /29 | 255.255.255.248 | 0.0.0.7 | 8 | 8 | 6 | 32 | /30 | 255.255.255.252 | 0.0.0.3 | 4 | 4 | 2 | 64 | Two more prefixes are worth knowing. A /31 contains two addresses and, under RFC 3021, both can be used on point-to-point links because a broadcast address is not needed there. A /32 identifies a single host and is commonly used for loopback interfaces and host routes. Note: The same patterns repeat in every octet. A /16 mask is 255.255.0.0, and /20 is 255.255.240.0, with a block size of 16 in the third octet, exactly like /28 in the fourth octet. ## The block size method: subnetting without binary Binary is the foundation, but you do not want to convert every address to ones and zeros under exam pressure. The block size method, sometimes called the "magic number" method, gets you the answer with simple arithmetic. - Find the interesting octet. This is the octet where the subnet mask is neither 255 nor 0. For /26 (255.255.255.192) it is the fourth octet. For /20 (255.255.240.0) it is the third. - Calculate the block size. Subtract the mask value in the interesting octet from 256. For /26 that is 256 − 192 = 64. - List the multiples. Subnets start at 0 and increase by the block size: 0, 64, 128, 192. - Find the network. The network address is the multiple equal to or just below the address's value in the interesting octet. - Find the broadcast. The broadcast is the next multiple minus 1. - Find the host range. First usable is network + 1; last usable is broadcast − 1. Octets to the left of the interesting octet are copied unchanged. Octets to the right are 0 in the network address and 255 in the broadcast address. That one rule handles every prefix length. ## Worked examples, step by step Work through these with a pen before reading the answers. Repetition is what makes subnetting fast. ### Example 1: Split 192.168.10.0/24 into four equal subnets You need four subnets. Because 22 = 4, you borrow 2 host bits, turning /24 into /26. The mask is 255.255.255.192, the block size is 64, and each subnet has 26 − 2 = 62 usable hosts. Subnet | Network | First usable | Last usable | Broadcast | 1 | 192.168.10.0/26 | 192.168.10.1 | 192.168.10.62 | 192.168.10.63 | 2 | 192.168.10.64/26 | 192.168.10.65 | 192.168.10.126 | 192.168.10.127 | 3 | 192.168.10.128/26 | 192.168.10.129 | 192.168.10.190 | 192.168.10.191 | 4 | 192.168.10.192/26 | 192.168.10.193 | 192.168.10.254 | 192.168.10.255 | ### Example 2: Which subnet does 192.168.1.130/26 belong to? (binary method) To see what the block size method is really doing, solve this one in binary. A router finds the network address by performing a bitwise AND between the address and the mask: a result bit is 1 only if both input bits are 1. Only the fourth octet is interesting here. Value | Decimal | Binary (4th octet) | Address | 130 | 10000010 | Mask | 192 | 11000000 | AND result | 128 | 10000000 | The network is 192.168.1.128/26. Setting the six host bits to 1 gives 10111111, which is 191, so the broadcast is 192.168.1.191. The usable range is 192.168.1.129 to 192.168.1.190. Check it with the block size method: multiples of 64 are 0, 64, 128 and 192, and 130 falls between 128 and 191. Same answer, much faster. ### Example 3: Find the network for 172.16.45.200/20 This one catches people because the interesting octet is not the last one. - A /20 mask is 255.255.240.0, so the interesting octet is the third. - Block size is 256 − 240 = 16. - Multiples of 16 in the third octet: 0, 16, 32, 48, 64 and so on. - The third octet of the address is 45, which falls between 32 and 47. The network starts at 32. - The fourth octet is to the right of the interesting octet, so it is 0 for the network and 255 for the broadcast. Result: network 172.16.32.0/20, broadcast 172.16.47.255, usable hosts 172.16.32.1 to 172.16.47.254. With 12 host bits, the subnet holds 212 − 2 = 4,094 usable hosts. Notice that addresses such as 172.16.40.0 and 172.16.39.255 are perfectly valid host addresses inside this subnet; only the very first and very last addresses are reserved. ### Example 4: Size a subnet for 500 hosts Here you work backward from a requirement. Find the smallest number of host bits where 2h − 2 is at least 500. - 8 host bits: 256 − 2 = 254. Too small. - 9 host bits: 512 − 2 = 510. Big enough. Nine host bits leaves 32 − 9 = 23 network bits, so you need a /23 with mask 255.255.254.0. If you allocate 10.20.0.0/23, the subnet runs from 10.20.0.0 to 10.20.1.255, with usable hosts from 10.20.0.1 to 10.20.1.254. A /23 must start on an even third octet, because the block size in that octet is 2. ### Check your answers with Python Python's built-in ipaddress module is a handy way to verify practice problems or generate address plans. This short script reproduces the examples above. ``` import ipaddress # Example 1: split a /24 into four /26 subnets for subnet in ipaddress.ip_network("192.168.10.0/24").subnets(new_prefix=26): hosts = list(subnet.hosts()) print(subnet, hosts[0], hosts[-1], subnet.broadcast_address) # Examples 2 and 3: find the network an address belongs to print(ipaddress.ip_interface("192.168.1.130/26").network) # 192.168.1.128/26 print(ipaddress.ip_interface("172.16.45.200/20").network) # 172.16.32.0/20 # Example 4: broadcast of a /23 print(ipaddress.ip_network("10.20.0.0/23").broadcast_address) # 10.20.1.255 ``` ## VLSM: sizing subnets to real needs Splitting a network into equal pieces is easy, but real networks rarely need equal pieces. A user VLAN may need 100 addresses while a router-to-router link needs two. Variable Length Subnet Masking (VLSM) lets you use different prefix lengths inside one block so nothing is wasted. The golden rule of VLSM is simple: allocate the largest subnets first. Doing so keeps every subnet aligned on a valid boundary for its size and prevents overlaps. ### VLSM example: carve up 10.10.0.0/24 You have been given 10.10.0.0/24 for a small site with these requirements: - Staff VLAN: 100 hosts - Engineering VLAN: 50 hosts - Management VLAN: 20 hosts - Two point-to-point router links: 2 hosts each Pick the smallest prefix that fits each requirement, then allocate from largest to smallest: Requirement | Prefix | Subnet | Usable range | Broadcast | Staff (100) | /25 (126 hosts) | 10.10.0.0/25 | 10.10.0.1 – 10.10.0.126 | 10.10.0.127 | Engineering (50) | /26 (62 hosts) | 10.10.0.128/26 | 10.10.0.129 – 10.10.0.190 | 10.10.0.191 | Management (20) | /27 (30 hosts) | 10.10.0.192/27 | 10.10.0.193 – 10.10.0.222 | 10.10.0.223 | Link A (2) | /30 (2 hosts) | 10.10.0.224/30 | 10.10.0.225 – 10.10.0.226 | 10.10.0.227 | Link B (2) | /30 (2 hosts) | 10.10.0.228/30 | 10.10.0.229 – 10.10.0.230 | 10.10.0.231 | The remaining space, 10.10.0.232 to 10.10.0.255, is still free and can be used as a /29 (10.10.0.232/29) and a /28 (10.10.0.240/28) for future needs. Applying one of these subnets on a Cisco router interface looks like this: ``` interface GigabitEthernet0/0/1 description Link A to BRANCH-RTR ip address 10.10.0.225 255.255.255.252 no shutdown ``` Watch out: Allocating small subnets first is the classic VLSM mistake. If you placed the /30 links at 10.10.0.0 and 10.10.0.4, you could no longer fit a /25 at the start of the block, because a /25 must begin at .0 or .128. ## Route summarization (supernetting) Summarization is subnetting in reverse. Instead of splitting a block into smaller pieces, you combine several contiguous networks into one shorter prefix. Summaries shrink routing tables, reduce the impact of individual link flaps and make ACLs and firewall policies easier to read. They are a core design technique in protocols such as OSPF, where summarization happens at area boundaries. ### How to find a summary - Write the networks in binary, at least the octet where they differ. - Count the number of leading bits they share. - The summary is the first network with a prefix length equal to the shared bits. Take 192.168.0.0/24 through 192.168.3.0/24. The third octets are 0, 1, 2 and 3, which in binary are 00000000, 00000001, 00000010 and 00000011. The first six bits are identical, so the summary keeps 16 + 6 = 22 bits: 192.168.0.0/22. Similarly, 172.16.8.0/24 through 172.16.15.0/24 share the bits 00001 in the third octet (8 is 00001000 and 15 is 00001111), so they summarize to 172.16.8.0/21. Note: A clean summary requires the networks to be contiguous and aligned to the summary's boundary. The networks 172.16.6.0/24 through 172.16.9.0/24 cross the boundary at 172.16.8.0, so the smallest single prefix covering all four is 172.16.0.0/20, which also claims twelve networks you do not own. In that case you would advertise two summaries (172.16.6.0/23 and 172.16.8.0/23) instead. This is why good addressing plans assign contiguous, aligned blocks to each site or function from the start. If you document your allocations as you go, which our network documentation guide covers in detail, summarization becomes almost automatic. ## Common subnetting mistakes and how to avoid them - Forgetting the minus 2. A /27 has 32 addresses but only 30 usable hosts. Size DHCP scopes and VLANs on usable hosts. - Using the wrong interesting octet. For prefixes between /17 and /23, the action is in the third octet. Always identify the octet before you start counting. - Treating x.x.x.0 or x.x.x.255 as always invalid. In larger subnets such as a /23 or /20, many addresses ending in .0 or .255 are ordinary host addresses. - Misaligned subnets. A /26 cannot start at .32. Network addresses must be multiples of the block size. - Overlapping allocations. Two subnets that overlap cause intermittent, confusing reachability problems. Track every allocation in a spreadsheet or IPAM tool. - Gateway outside the subnet. If a host's default gateway is not inside its own subnet, it cannot ARP for it, and off-subnet traffic fails. Once you are comfortable with IPv4, apply the same thinking to IPv6. The address is longer, but prefix logic is the same, and standard /64 subnets make many decisions simpler. Our IPv6 guide for network admins is a natural next step, and subnetting practice fits neatly into week two of our 90-day CCNA study plan. ## Key takeaways - An IPv4 address is 32 bits; the mask or CIDR prefix tells you which bits are network and which are host. - Total addresses equal 2h and usable hosts equal 2h − 2, except on /31 point-to-point links (RFC 3021). - The block size method (256 minus the mask value in the interesting octet) lets you find network, broadcast and host range without binary. - Network addresses are always multiples of the block size in the interesting octet. - With VLSM, size each subnet to its real needs and allocate the largest subnets first. - Summarization combines contiguous, aligned networks into one shorter prefix and depends on a well-planned addressing scheme. - Practice daily for a couple of weeks and subnetting becomes automatic. Practice is what turns these rules into instinct, so try a handful of problems every day and check your answers with our subnet calculator. If your organization's addressing has grown messy over the years, with overlapping ranges, undocumented subnets or no room to summarize, our Network Health Assessment can map what you have and propose a clean plan. ## FAQ Q: Why do we subtract 2 when calculating usable hosts? A: In a traditional IPv4 subnet, the first address (all host bits set to 0) identifies the network itself and the last address (all host bits set to 1) is the directed broadcast address. Neither can be assigned to a host, so usable hosts equal 2 to the power of the host bits, minus 2. The exception is a /31 point-to-point link defined in RFC 3021, where both addresses are usable. Q: What is the difference between a subnet mask and CIDR notation? A: They express the same information in different formats. A subnet mask such as 255.255.255.192 is written in dotted decimal, while CIDR notation such as /26 simply counts the number of leading 1 bits in that mask. 255.255.255.192 has 26 leading ones, so it is /26. Q: What is the fastest way to subnet in my head? A: Use the block size method. Find the interesting octet (the one where the mask is neither 255 nor 0), subtract the mask value in that octet from 256 to get the block size, and count up in multiples of the block size. The multiple at or just below your address is the network, and the next multiple minus one is the broadcast. Q: What is VLSM and why is it used? A: Variable Length Subnet Masking means using different prefix lengths within the same address block, so each subnet is sized to its actual needs. It avoids wasting addresses, for example by using a /30 or /31 for a point-to-point link instead of a /24. Always allocate the largest subnets first to keep boundaries aligned. Q: Which IPv4 address ranges are private? A: RFC 1918 defines three private ranges: 10.0.0.0/8, 172.16.0.0/12 (172.16.0.0 to 172.31.255.255) and 192.168.0.0/16. These addresses are not routed on the public internet and are normally translated with NAT when hosts need internet access. --- # VLANs Explained: Design, Trunking and Inter-VLAN Routing URL: https://roadtoneteng.com/vlans-explained/ Updated: 2026-10-14 VLANs are one of the first things you configure on a new switch and one of the last things you suspect when something breaks. They are simple in concept: split one physical switch into several logical ones. Yet trunks, native VLANs and inter-VLAN routing hide a handful of details that trip up admins and engineers alike. This guide explains how VLANs work under the hood, how to design them sensibly, and exactly how to configure access ports, 802.1Q trunks, router-on-a-stick and switched virtual interfaces on Cisco IOS. ## What a VLAN actually is A Virtual Local Area Network (VLAN) is a logical broadcast domain created on a switch. Without VLANs, every port on a switch belongs to the same broadcast domain: an ARP request or DHCP discover from one device is flooded to every other port. With VLANs, the switch keeps a separate MAC address table and flooding scope for each VLAN. A broadcast in VLAN 10 never leaves VLAN 10. The practical effect is that ports in different VLANs behave as though they were on physically separate switches. Two PCs in different VLANs cannot talk to each other directly, even if they are plugged into adjacent ports. To communicate, their traffic must pass through a Layer 3 device, either a router or a Layer 3 switch, which is also where you can apply security policy. A widely used design convention is one VLAN equals one IP subnet. VLAN 10 might be 10.1.10.0/24, VLAN 20 might be 10.1.20.0/24, and so on. Keeping that mapping one-to-one makes troubleshooting, documentation and access control far simpler. If you need a refresher on carving up address space for each VLAN, see our guide to subnetting and CIDR. ## Why VLANs matter VLANs solve several problems at once, which is why virtually every business network uses them: - Segmentation and security. Guest Wi-Fi, IP cameras, payment terminals and staff PCs should not share a flat network. VLANs give you boundaries where you can filter traffic with ACLs or a firewall. - Smaller broadcast domains. Every broadcast must be processed by every host in its domain. Smaller domains mean less noise and contain the impact of problems such as broadcast storms. - Flexibility. Users can be grouped by function rather than by physical location. Moving a user to a different department becomes a configuration change rather than a cabling job. - Quality of service. Putting IP phones in a dedicated voice VLAN makes it easy to identify and prioritize voice traffic. - Operational clarity. A well-planned VLAN scheme tells you at a glance what a device is and what it should be allowed to reach. ## Designing a sensible VLAN scheme Good VLAN design starts on paper, not on the switch. A few decisions made early will save you years of confusion. ### Group by function and trust level Create VLANs based on what devices do and how much you trust them, not on the org chart. A typical small or mid-sized business might use something like this: VLAN ID | Name | Purpose | Example subnet | 10 | STAFF | Employee PCs and laptops | 10.1.10.0/24 | 20 | VOICE | IP phones | 10.1.20.0/24 | 30 | PRINTERS-IOT | Printers, displays, building systems | 10.1.30.0/24 | 40 | SERVERS | On-premises servers | 10.1.40.0/24 | 50 | GUEST | Guest Wi-Fi, internet only | 10.1.50.0/24 | 99 | MGMT | Switch, AP and firewall management | 10.1.99.0/24 | 999 | NATIVE-UNUSED | Native VLAN on trunks, carries no user traffic | None | Notice the convention of matching the VLAN ID to the third octet of the subnet. It is not required, but it makes it obvious that 10.1.30.15 lives in VLAN 30. ### Avoid VLAN 1 for real traffic VLAN 1 is the default VLAN on Cisco switches. Every port starts there, and many control protocols such as CDP and VTP use it. It cannot be deleted. Best practice is to leave VLAN 1 empty of users and management traffic, move all active ports into purpose-built VLANs, and place unused ports in a dedicated "parking" VLAN while keeping them shut down. ### Keep VLANs local where you can Stretching a VLAN across an entire campus means stretching its broadcast domain and its spanning tree topology along with it. Modern designs generally keep Layer 2 domains small, often confined to an access switch or a wiring closet, and route everywhere else. That limits the blast radius of loops and makes failures easier to isolate. ### Be careful with VTP VLAN Trunking Protocol can synchronize the VLAN database across switches, but a switch with a higher configuration revision number can overwrite VLANs across the whole domain if it is introduced carelessly. Many engineers run VTP in transparent mode, or disable it where supported, and manage VLANs explicitly or through automation instead. Pro tip: Record every VLAN's ID, name, subnet, gateway, DHCP scope and purpose in one place before you configure anything. That single table becomes the reference for configuration, firewall rules and troubleshooting. ## Configuring access ports An access port belongs to exactly one data VLAN and sends and receives untagged Ethernet frames. End devices such as PCs, printers and cameras connect to access ports and have no idea a VLAN exists. First, create and name the VLANs: ``` vlan 10 name STAFF vlan 20 name VOICE vlan 99 name MGMT vlan 999 name NATIVE-UNUSED ``` Then configure the access port. This example is a desk port with a PC plugged into an IP phone: ``` interface GigabitEthernet1/0/5 description Desk 2.14 - PC and phone switchport mode access switchport access vlan 10 switchport voice vlan 20 switchport nonegotiate spanning-tree portfast spanning-tree bpduguard enable no shutdown ``` Here is what each line does: - switchport mode access hard-codes the port as an access port so it never forms a trunk. - switchport access vlan 10 places untagged traffic, the PC behind the phone, into VLAN 10. - switchport voice vlan 20 tells the phone, typically via CDP or LLDP-MED, to tag its own voice traffic with VLAN 20. - switchport nonegotiate disables Dynamic Trunking Protocol (DTP) messages on the port. - spanning-tree portfast lets the port start forwarding immediately instead of waiting through listening and learning, which avoids DHCP timeouts on boot. - spanning-tree bpduguard enable err-disables the port if a switch is plugged in, protecting the spanning tree topology. Unused ports should be parked and shut down: ``` interface range GigabitEthernet1/0/40 - 47 description UNUSED switchport mode access switchport access vlan 998 shutdown ``` Note: If you assign a port to a VLAN that does not exist yet, many Cisco switches will create it automatically, while others show the port as inactive. Create VLANs explicitly first so the database matches your documentation. ## Trunking with 802.1Q A trunk carries traffic for many VLANs over a single link, typically between switches, or between a switch and a router, firewall, wireless access point or hypervisor. To keep frames from different VLANs apart on that shared link, the sender tags each frame using the IEEE 802.1Q standard. ### How the 802.1Q tag works The switch inserts a 4-byte tag into the Ethernet frame between the source MAC address and the EtherType field. The tag contains: - TPID (16 bits): set to 0x8100, identifying the frame as 802.1Q tagged. - PCP (3 bits): the priority code point, used for 802.1p class of service markings. - DEI (1 bit): drop eligible indicator, formerly called CFI. - VID (12 bits): the VLAN identifier. Twelve bits give 4,096 possible values, but 0 and 4095 are reserved, so VLAN IDs 1 to 4094 are usable. The tag also increases the maximum standard frame size from 1,518 to 1,522 bytes. The receiving switch reads the VID, removes the tag and forwards the frame only to ports in that VLAN. ### The native VLAN One VLAN on each trunk is sent untagged: the native VLAN, which defaults to VLAN 1. Any untagged frame that arrives on a trunk is placed into the native VLAN. The native VLAN must match on both ends of the link. If it does not, traffic from one VLAN silently leaks into another, and Cisco switches running CDP will log a native VLAN mismatch message. Best practice is to set the native VLAN to a dedicated, unused VLAN such as 999 on every trunk. This also mitigates double-tagging VLAN hopping attacks, which rely on an attacker sitting in the native VLAN. ### Trunk configuration ``` interface GigabitEthernet1/0/48 description Uplink to DIST-SW1 Gi1/0/1 switchport trunk encapsulation dot1q switchport mode trunk switchport trunk native vlan 999 switchport trunk allowed vlan 10,20,30,40,50,99 switchport nonegotiate no shutdown ``` - switchport trunk encapsulation dot1q is only needed, and only accepted, on platforms that also support the older Cisco ISL encapsulation. Switches that only support 802.1Q, such as most current Catalyst models, do not need it. - switchport mode trunk forces trunking rather than relying on DTP negotiation. - switchport trunk allowed vlan restricts the trunk to the VLANs that are actually needed downstream, which limits flooding and spanning tree scope. - switchport nonegotiate stops DTP frames, preventing an attacker from negotiating a trunk. Watch out: switchport trunk allowed vlan 60 replaces the entire allowed list with VLAN 60, instantly cutting every other VLAN on that trunk. To add a VLAN to an existing list, always use switchport trunk allowed vlan add 60. ### A word on DTP Dynamic Trunking Protocol lets Cisco switches negotiate whether a link should become a trunk. A port in dynamic desirable mode actively tries to form a trunk, while dynamic auto waits to be asked. Two ports in dynamic auto never form a trunk. Negotiation is convenient in a lab, but in production it is safer to set every port explicitly to access or trunk and disable DTP with switchport nonegotiate. ## Inter-VLAN routing options Because each VLAN is its own subnet and broadcast domain, traffic between VLANs needs a Layer 3 hop. Each VLAN needs a default gateway address on a routing device. There are three ways to provide that: Method | How it works | Best for | Drawbacks | Separate router interfaces | One physical router port per VLAN, each connected to an access port | Rarely used today | Does not scale; uses many ports and cables | Router-on-a-stick | One router port configured as a trunk with a subinterface per VLAN | Small sites, branches, labs | All inter-VLAN traffic shares one link and the router's forwarding capacity | Layer 3 switch with SVIs | A virtual VLAN interface on the switch acts as each VLAN's gateway | Campus networks, most mid-sized sites | Requires a Layer 3 capable switch | In many small businesses, the "router" in router-on-a-stick is actually the firewall, with a subinterface per VLAN. That design puts security policy directly between VLANs, which is attractive when traffic volumes are modest. ## Router-on-a-stick configuration With router-on-a-stick, the switch port facing the router is a normal 802.1Q trunk, configured as shown above. On the router, the physical interface is enabled without an IP address, and a subinterface is created for each VLAN: ``` interface GigabitEthernet0/0/1 description Trunk to ACCESS-SW1 Gi1/0/48 no ip address no shutdown ! interface GigabitEthernet0/0/1.10 description STAFF gateway encapsulation dot1Q 10 ip address 10.1.10.1 255.255.255.0 ip helper-address 10.1.40.10 ! interface GigabitEthernet0/0/1.20 description VOICE gateway encapsulation dot1Q 20 ip address 10.1.20.1 255.255.255.0 ip helper-address 10.1.40.10 ! interface GigabitEthernet0/0/1.99 description MGMT gateway encapsulation dot1Q 99 ip address 10.1.99.1 255.255.255.0 ! interface GigabitEthernet0/0/1.999 description Native VLAN - no IP encapsulation dot1Q 999 native ``` Key points to remember: - The subinterface number does not have to match the VLAN ID, but matching them is a strong convention that prevents mistakes. - encapsulation dot1Q must be configured before an IP address can be applied to the subinterface. - The native keyword tells the router which VLAN arrives untagged, and it must match the switch's native VLAN. - ip helper-address forwards DHCP broadcasts (UDP ports 67 and 68) from the VLAN to a DHCP server in another subnet, here a server in VLAN 40. - If the physical interface is shut down, every subinterface goes down with it. ## Inter-VLAN routing with SVIs on a Layer 3 switch A switched virtual interface (SVI) is a logical Layer 3 interface for a VLAN on a multilayer switch. The switch routes between SVIs in hardware, so throughput is typically far higher than router-on-a-stick, and no external trunk to a router is needed for traffic between local VLANs. ``` ip routing ! interface Vlan10 description STAFF gateway ip address 10.1.10.1 255.255.255.0 ip helper-address 10.1.40.10 no shutdown ! interface Vlan20 description VOICE gateway ip address 10.1.20.1 255.255.255.0 ip helper-address 10.1.40.10 no shutdown ! interface Vlan99 description MGMT gateway ip address 10.1.99.1 255.255.255.0 no shutdown ! interface GigabitEthernet1/0/1 description Routed uplink to FIREWALL no switchport ip address 10.1.255.2 255.255.255.252 no shutdown ! ip route 0.0.0.0 0.0.0.0 10.1.255.1 ``` - ip routing enables IPv4 routing on the switch. Without it, the SVIs exist but the switch will not route between them. - Each interface VlanX becomes the default gateway for hosts in that VLAN. - no switchport turns a physical port into a routed port, used here as a point-to-point /30 uplink to the firewall. - The default route sends everything that is not local towards the firewall. In larger networks you would run a dynamic routing protocol such as OSPF on the uplinks instead. An SVI only comes up when its VLAN exists and at least one port carrying that VLAN, an access port or a trunk that allows it, is up and in the spanning tree forwarding state. This behavior is called autostate, and it is the most common reason a freshly configured SVI stays down. Watch out: Once a Layer 3 switch routes between all your VLANs, anything can reach anything unless you add filtering. Apply ACLs on the SVIs or route sensitive VLANs such as GUEST and IOT through the firewall instead of giving them an SVI. Our firewall hardening checklist covers how to build that policy. ## Verification and troubleshooting When users in a VLAN cannot reach their gateway, or a new VLAN does not work across a trunk, work through the path methodically rather than changing things at random. These commands answer the most important questions: ``` show vlan brief show interfaces GigabitEthernet1/0/5 switchport show interfaces trunk show mac address-table vlan 10 show spanning-tree vlan 10 show ip interface brief show ip route ``` Symptom | Likely cause | What to check | Host gets a 169.254.x.x address | Wrong access VLAN, missing helper address, or VLAN not allowed on the trunk | show interfaces switchport, show interfaces trunk, helper address on the gateway | Port shows VLAN as inactive | VLAN does not exist in the VLAN database | show vlan brief; create the VLAN | VLAN works on one switch but not across the uplink | VLAN missing from the allowed list, pruned, or not created on the far switch | "VLANs allowed and active" section of show interfaces trunk | Traffic appears in the wrong VLAN, CDP mismatch logs | Native VLAN mismatch | Native VLAN column of show interfaces trunk on both ends | Trunk will not form | One side is an access port or both are dynamic auto | show interfaces switchport administrative and operational mode | SVI is down/down | No active port in the VLAN, or the VLAN is not created | Autostate conditions, show vlan brief | Hosts reach the gateway but not other VLANs | ip routing disabled, an ACL, or a wrong default gateway on hosts | show ip route, interface ACLs, host IP settings | Work from the bottom up: physical link, access VLAN, trunk allowed list and native VLAN, spanning tree state, gateway interface, then routing and filtering. A disciplined approach like the one in our network troubleshooting methodology guide will find the fault faster than guessing. The best place to practice all of this is a lab where you can break trunks on purpose; our guide to building a home network lab shows you how to set one up. ## Key takeaways - A VLAN is a separate broadcast domain on a switch; map each VLAN to exactly one IP subnet. - Design VLANs by function and trust level, keep VLAN 1 empty, and park unused ports in a shut-down VLAN. - Access ports carry one untagged data VLAN plus an optional voice VLAN; harden them with PortFast, BPDU Guard and switchport nonegotiate. - 802.1Q trunks insert a 4-byte tag with a 12-bit VLAN ID; usable IDs are 1 to 4094. - Set a dedicated, matching native VLAN on every trunk and restrict the allowed VLAN list, using add when extending it. - Router-on-a-stick suits small sites and labs; SVIs on a Layer 3 switch are the norm for higher-throughput networks. - Inter-VLAN routing opens paths between segments, so filter traffic with ACLs or a firewall deliberately. A clean VLAN design is one of the highest-value improvements you can make to a growing network. If your switches have grown into a flat network or a tangle of undocumented VLANs, our Small Business Network Setup service can design and deploy a segmented, documented network for you, or you can contact us to talk through your current setup. ## FAQ Q: What is the difference between an access port and a trunk port? A: An access port belongs to a single data VLAN and sends and receives untagged frames, which is what end devices such as PCs and printers expect. A trunk port carries traffic for multiple VLANs over one link and identifies each frame's VLAN with an 802.1Q tag, except for the native VLAN, which is sent untagged. Q: What is the native VLAN and should I change it? A: The native VLAN is the VLAN whose traffic crosses an 802.1Q trunk without a tag. On Cisco switches it defaults to VLAN 1. A common best practice is to set the native VLAN to a dedicated, unused VLAN on every trunk, make sure it matches on both ends, and avoid carrying user traffic in it. This reduces the risk of double-tagging VLAN hopping attacks. Q: Should I use router-on-a-stick or a Layer 3 switch for inter-VLAN routing? A: Router-on-a-stick is fine for small sites, labs and branches with modest traffic, because it needs only one router interface. A Layer 3 switch with SVIs routes in hardware at much higher throughput and is the normal choice for campus networks and any site with significant traffic between VLANs. Q: How many VLANs can I create? A: The 802.1Q VLAN ID field is 12 bits, giving values from 0 to 4095. IDs 0 and 4095 are reserved, so 1 to 4094 are usable. On Cisco switches, 1 to 1005 is the normal range (with 1002 to 1005 reserved for legacy uses), and 1006 to 4094 is the extended range. Individual platforms may support fewer active VLANs, so check your model's limits. Q: Why is my SVI down even though I configured no shutdown? A: On Cisco switches an SVI only comes up when the VLAN exists in the VLAN database and at least one port carrying that VLAN, either an access port or a trunk that allows it, is up and forwarding. Create the VLAN, check that a port is assigned to it or allowed on a trunk, and confirm that ip routing is enabled if you expect the switch to route. --- # How to Build a Home Network Lab on Any Budget URL: https://roadtoneteng.com/build-a-home-network-lab/ Updated: 2026-10-14 You can read about spanning tree, OSPF and VLAN trunking for months, but nothing makes them click like building a network yourself, breaking it and fixing it again. A home network lab is the single best investment you can make in your networking career, and it does not have to be expensive. Whether you have zero budget and a laptop or room for a small rack of used equipment, this guide shows you how to choose between physical and virtual options, what hardware to run it on, and how to design a lab that grows with your skills. ## Why every network professional needs a lab A lab gives you something production never can: permission to fail. In a lab you can mismatch OSPF timers, create a switching loop, misconfigure a native VLAN or lock yourself out with an ACL, and the only consequence is learning. That freedom is what turns memorized facts into the intuition you need under pressure. A lab also helps you: - Prepare for certifications. Exams such as the CCNA test hands-on configuration and troubleshooting skills, not just theory. - Test changes safely. Before you touch a production switch, you can rehearse the exact change and the rollback in a lab. - Learn new vendors and technologies. Multi-vendor labs let you compare platforms without buying them. - Practice automation. Scripts and playbooks need devices to talk to, and a lab is the safest place to run untested code. - Build a portfolio. Documented lab projects are excellent material for interviews, especially if you are working your way from network administrator to network engineer. ## Start with your goals, not your shopping list The most common home lab mistake is buying equipment first and figuring out what to do with it later. Decide what you want to learn over the next six to twelve months, then build the smallest lab that supports it. Goal | What the lab needs | Good starting platform | CCNA or general fundamentals | A few switches and routers, VLANs, OSPF, NAT, DHCP, ACLs | Packet Tracer, then GNS3, EVE-NG or Cisco Modeling Labs | Professional-level routing and switching | Many routers, real IOS or IOS XE images, BGP, multi-area OSPF, redistribution | EVE-NG, GNS3 or Cisco Modeling Labs | Network automation | Devices with SSH and APIs, a Linux host with Python and Ansible, version control | Containerlab, plus any emulator with API-capable images | Security and firewalls | A virtual or physical firewall, several segments, a few client VMs | A hypervisor with an open source firewall plus an emulator | Wireless | Physical access points and client devices | Physical gear; RF cannot be meaningfully virtualized | Pro tip: Write your goal at the top of a lab notebook or repository README, for example "Pass the CCNA in 90 days" or "Automate VLAN provisioning with Ansible." Every purchase and topology decision should serve that goal. ## Physical vs. virtual: the honest trade-offs There is a long-running debate about whether a "real" lab needs physical gear. The honest answer is that both have strengths, and most experienced engineers end up with a mostly virtual lab plus a little hardware. Factor | Physical lab | Virtual lab | Upfront cost | Moderate; used gear can be inexpensive per device | Free to low if you already own a capable computer | Scale | Limited by budget, space and power | Dozens of devices on a single host with enough RAM | Realism | Real cabling, consoles, ASIC behavior, PoE and boot processes | Real software in emulators; limited hardware-specific features | Flexibility | Recabling takes time | New topologies in minutes; save and snapshot labs | Noise, heat, power | Enterprise gear can be loud and power hungry | Quiet, efficient on modern hardware | Software currency | Affordable used gear often runs older, unsupported releases | Can run current images where licensing allows | Wireless and PoE | Fully supported | Not realistically possible | For most learners, virtual should come first. It is cheaper, more flexible and covers the overwhelming majority of routing and switching topics. Add physical gear when you want hands-on experience with consoles, cabling, PoE, wireless or specific hardware features. ## Virtual lab platforms compared Each major platform has a different philosophy. Understanding those differences helps you pick the right tool, or the right combination, for your goals. ### Cisco Packet Tracer Packet Tracer is a free network simulator available through Cisco's Networking Academy. It runs on Windows, macOS and Linux and needs very little computing power. Because it is a simulator rather than an emulator, it implements a subset of IOS commands and features rather than running real IOS. That makes it ideal for beginners and for most CCNA topics, and its simulation mode, which lets you watch packets move step by step, is an excellent teaching tool. You will eventually outgrow it when you need advanced features or exact real-device behavior. ### GNS3 GNS3 is a free, open source network emulator with a desktop client and a large community. It runs real network operating system images using QEMU/KVM virtualization, older Cisco router images via the Dynamips emulator, and Docker containers. On Windows and macOS, the recommended setup runs the heavy lifting inside the GNS3 VM, while the desktop client handles the topology. GNS3 can also connect lab devices to your real network through cloud nodes, which is handy for testing automation from your workstation. ### EVE-NG EVE-NG (Emulated Virtual Environment, Next Generation) is a multi-vendor emulation platform that you install as a virtual machine or directly on a dedicated server, then manage through a web browser. A free Community Edition covers most home lab needs, while the paid Professional edition adds features aimed at power users and teams. Its browser-based interface makes it convenient to run on a separate server and access from any computer, which suits a dedicated home lab host well. ### Containerlab Containerlab is an open source tool that builds network topologies from containerized network operating systems on a Linux host. You describe the topology in a YAML file, deploy it with a single command, and destroy it just as quickly. It supports container-native platforms such as Nokia SR Linux, Arista cEOS, Juniper cRPD and FRRouting, and can also wrap some VM-based images. Because topologies are just text files, Containerlab fits naturally into Git and CI pipelines, making it a favorite for network automation work. Container-based nodes are also much lighter on RAM than full virtual machines. ### Cisco Modeling Labs Cisco Modeling Labs (CML) is Cisco's official network simulation platform. The personal license includes legally licensed Cisco images such as IOSv, IOS XE, NX-OS and others, which removes the most common headache in Cisco-focused labs: obtaining images legitimately. Cisco has also offered a free tier with a limited node count; check Cisco's site for current editions and terms. ### Platform comparison at a glance Platform | Type | Cost model | Runs real images | Best for | Packet Tracer | Simulator | Free with Networking Academy account | No | Beginners, CCNA fundamentals | GNS3 | Emulator | Free, open source | Yes (bring your own images) | Flexible multi-vendor labs on a workstation | EVE-NG | Emulator | Free Community, paid Professional | Yes (bring your own images) | Larger labs on a dedicated host, browser access | Containerlab | Container orchestration | Free, open source | Yes (container NOS images) | Automation, lab-as-code, lightweight topologies | Cisco Modeling Labs | Emulator | Paid personal license; limited free tier offered | Yes (Cisco images included) | Cisco certification labs with licensed images | Watch out: Only run images you are licensed to use. Images from unofficial download sites can be tampered with, and running them may breach vendor license terms. Licensed bundles, employer support contracts and freely published images from vendors are the safe options. ## Lab as code: a quick Containerlab example To see how lightweight a modern lab can be, here is a complete two-router Containerlab topology using Nokia SR Linux, which is freely available as a container image. Save it as two-node.clab.yml on a Linux host with Docker installed: ``` name: two-node topology: nodes: srl1: kind: nokia_srlinux image: ghcr.io/nokia/srlinux srl2: kind: nokia_srlinux image: ghcr.io/nokia/srlinux links: - endpoints: ["srl1:e1-1", "srl2:e1-1"] ``` Deploy, inspect, connect and tear down the lab with a handful of commands: ``` sudo containerlab deploy -t two-node.clab.yml sudo containerlab inspect -t two-node.clab.yml docker exec -it clab-two-node-srl1 sr_cli sudo containerlab destroy -t two-node.clab.yml ``` Containerlab names each node clab-- and gives it a management address, so you can reach it with SSH or point automation tools at it immediately. Commit the YAML file to Git and you have a reproducible lab you can rebuild anywhere in under a minute. In production use, pin a specific image tag rather than relying on the latest one, so your lab behaves the same every time. ## Choosing physical gear If you want hardware, buy deliberately. A small, quiet setup that you actually power on is worth more than a full rack that stays off because of the noise. ### What to look for - Switches. Two or three managed switches let you practice VLANs, trunks, EtherChannel and spanning tree. At least one Layer 3 capable model lets you practice SVIs and inter-VLAN routing. Older Catalyst models in the 2960 and 3560 families are common in CCNA labs. - Routers. One or two routers with spare interfaces cover NAT, DHCP, static routing and OSPF. Older Integrated Services Router generations are widely available used. - Firewall. An open source firewall distribution on a small multi-NIC mini PC is an inexpensive way to practice segmentation and VPNs. - Wireless. A business-grade access point that supports multiple SSIDs mapped to VLANs teaches far more than a consumer router. - Accessories. A USB console cable, a few patch cables of different colors for different purposes, and a labeled power strip. ### Practical considerations Enterprise switches and routers are designed for data centers and wiring closets, not spare bedrooms. Before you buy, check the fan noise, power draw and heat output, and look for fanless or compact models when the lab will share space with people. Confirm that the device's software release supports the features you want to practice; very old releases may lack commands that appear in current exam blueprints. Note: Many affordable used devices are past their vendor's end-of-support date and no longer receive security fixes. That is fine for an isolated lab, but never connect them to the internet directly or reuse them in a production network. ## Hardware for a virtual lab host For virtual labs, the host computer matters more than anything else. Emulated network devices are surprisingly hungry, and the bottleneck is almost always memory. - RAM. This is your scaling limit. Lightweight images and containers need a few hundred megabytes, while full virtual routers and data center switch images can need several gigabytes each. As a rough guide, 16 GB handles small labs, 32 GB is comfortable for CCNA-level work, and 64 GB or more suits large multi-vendor topologies. - CPU. Hardware virtualization support (Intel VT-x or AMD-V) is essential. More cores let you boot and run more devices at once. If you run an emulator inside another hypervisor, you also need nested virtualization enabled. - Storage. Use an SSD. Booting many virtual devices from a spinning disk is painfully slow. - Form factor. A mini PC or a used business workstation is quiet and efficient. Used rack servers offer lots of RAM cheaply but are often loud and power hungry. A popular approach is to install a bare-metal hypervisor such as Proxmox VE on a dedicated box, then run EVE-NG or the GNS3 VM, a Containerlab host, a firewall VM and a few Linux and Windows client VMs side by side. That turns one quiet machine into a flexible, always-available lab you can reach from your laptop. ## Budget tiers: what to build at each price point Here are four practical tiers. Prices for used hardware vary widely by region, condition and timing, so treat the ranges below as rough ballpark figures in US dollars rather than quotes. Tier | Approximate budget | What you get | What you can learn | Starter | $0 | Your existing computer with Packet Tracer, plus GNS3 or Containerlab with free images such as FRRouting or SR Linux | CCNA fundamentals, routing protocols, basic automation | Hands-on | Around $100–$300 | A RAM upgrade for your computer, or two used managed switches, a used router and a console cable | Physical cabling and console skills, VLANs, trunks, STP, inter-VLAN routing | Dedicated host | Around $300–$800 | A mini PC or used workstation with 64 GB RAM running a hypervisor, plus one small physical switch | Large virtual topologies, multi-vendor labs, firewalls, automation pipelines | Advanced | $800 and up | A more powerful host or several hosts, licensed simulation software, physical switches, a firewall and a business-grade access point | Professional-level labs, wireless, security, realistic campus and branch designs | Start at the lowest tier that serves your current goal. You can always add hardware later, and you will make much better purchasing decisions once you know what your labs actually need. ## First labs and best practices Once your lab is running, structure matters as much as hardware. Good habits here mirror good habits in production. ### Keep the lab isolated Connect your lab to your home network through a single, controlled point, such as a firewall VM or a dedicated router performing NAT. Never let a lab DHCP server or a spanning tree experiment leak onto the network your family or housemates use. If your home switch supports VLANs, give the lab its own VLAN. ### Document and version everything Keep a simple diagram, an addressing table and the goal of each lab. Store configurations, topology files and scripts in a Git repository. This builds exactly the documentation habits employers look for and lets you rebuild any lab quickly. ### Good first projects - Build a three-VLAN network with trunks and router-on-a-stick, then convert it to SVIs on a Layer 3 switch, following our VLAN design and trunking guide. - Connect three routers with point-to-point links and run single-area OSPF, then add a second area and summarize at the boundary using our OSPF fundamentals article. - Add NAT, DHCP and ACLs so that one VLAN can reach the internet but not another VLAN. - Write a Python script that logs in to every lab device and backs up its configuration. - Break each lab on purpose, then fix it using only show commands. If you are preparing for a certification, map your labs directly to the exam blueprint. Our 90-day CCNA study plan includes a weekly lab focus you can follow. ## Key takeaways - Define what you want to learn first, then build the smallest lab that supports that goal. - Virtual labs cover most routing and switching topics and are cheaper and more flexible; physical gear adds cabling, console, PoE and wireless experience. - Packet Tracer suits beginners, GNS3 and EVE-NG run real multi-vendor images, Containerlab brings lab-as-code for automation, and Cisco Modeling Labs includes licensed Cisco images. - RAM is the main constraint for virtual labs; an SSD and a CPU with virtualization support are essential. - Use only properly licensed images, and keep older, unsupported hardware isolated from the internet. - Isolate your lab from your home network, document it, and keep configurations in Git. A well-designed lab pays for itself many times over in skills, confidence and career progress. If you want a lab tailored to your goals and budget, with a parts list, topology and first lab exercises ready to go, take a look at our Home Lab Blueprint and Build Consultation or contact us with your questions. ## FAQ Q: Do I need physical equipment to study for the CCNA? A: No. Cisco Packet Tracer and virtual platforms such as GNS3, EVE-NG or Cisco Modeling Labs cover almost everything on the exam blueprint. Physical gear adds valuable experience with cabling, console access and real hardware behavior, but it is optional, especially when you are starting out. Q: Is GNS3 or EVE-NG better for a home lab? A: Both are capable multi-vendor emulators that run real network operating system images. GNS3 is free and open source with a desktop client and a large community. EVE-NG is browser-based and popular for larger, shared or multi-vendor labs, with a free Community Edition and a paid Professional edition. Try both and pick the workflow you prefer. Q: How much RAM do I need for a virtual network lab? A: It depends on the images you run. Lightweight images and containers need a few hundred megabytes each, while full virtual routers and data center switch images can need several gigabytes each. As a rough guide, 16 GB works for small labs, 32 GB is comfortable for CCNA-level topologies, and 64 GB or more suits larger multi-vendor labs. Q: Where can I legally get network device images for GNS3 or EVE-NG? A: Use images you are licensed to run. Options include images bundled with Cisco Modeling Labs, images available through your employer's support contracts, and vendors that publish free lab images or containers, such as Nokia SR Linux and the open source FRRouting suite. Avoid downloading images from unofficial sources. Q: Is old used Cisco equipment safe to use in a lab? A: It is fine for learning as long as it stays isolated. Many inexpensive used switches and routers are past end of support and no longer receive security fixes, so never expose them to the internet or use them in production. Also consider noise, heat and power draw before buying rack-mounted gear for your home. --- # A 90-Day CCNA Study Plan That Actually Works URL: https://roadtoneteng.com/ccna-study-plan/ Updated: 2026-10-14 Most people who fail to earn the CCNA do not fail because the material is too hard. They fail because they study without a plan: weeks of enthusiastic reading, a stall around spanning tree, a vague sense of "almost ready," and an exam date that keeps slipping. This 90-day CCNA study plan fixes that. It breaks the 200-301 blueprint into thirteen focused weeks, pairs every topic with hands-on labs, and builds in review so you walk into the exam room confident rather than hopeful. ## Before you start: is 90 days realistic? Ninety days is an ambitious but achievable target for many candidates. Whether it is realistic for you depends on three things: your starting point, the time you can commit each week, and how consistently you can stick to the schedule. - If you already work in IT, perhaps as a help desk technician or network administrator, you likely know some fundamentals already, and 90 days is very realistic. - If you are new to networking, the plan still works, but expect some weeks to take longer. Extending to four or five months is perfectly fine. - If your schedule is unpredictable, treat the weeks as phases rather than fixed dates and focus on completing each phase properly. Plan for roughly eight to twelve hours of study per week: about an hour or two on most weekdays and a longer lab session at the weekend. That is a sustainable pace alongside a full-time job, and consistency beats intensity every time. Pro tip: Book your exam for around day 90 once you have finished the first two or three weeks and know you can keep the pace. A real date on the calendar is one of the strongest motivators there is, and you can usually reschedule within the testing provider's policy if life gets in the way. ## Understanding the CCNA 200-301 exam domains The CCNA 200-301 blueprint is organized into six domains. Cisco publishes the full list of exam topics, including the relative weighting of each domain, on its official certification site. Blueprints are revised from time to time, so download the current version before you start and use it as your master checklist. Domain | What it covers | Network Fundamentals | Network components and topologies, cabling and interfaces, TCP and UDP, IPv4 and IPv6 addressing and subnetting, wireless principles, virtualization and switching concepts | Network Access | VLANs, trunking, Layer 2 discovery protocols, EtherChannel, Rapid PVST+ spanning tree, wireless architectures and access point modes, WLAN management access | IP Connectivity | The routing table, forwarding decisions, IPv4 and IPv6 static routing, single-area OSPFv2 and the purpose of first hop redundancy protocols | IP Services | NAT, NTP, DHCP and DNS, SNMP, syslog, QoS concepts, SSH remote access, TFTP and FTP | Security Fundamentals | Security concepts and programs, device access control, passwords and MFA, VPNs, ACLs, Layer 2 security features, AAA and wireless security | Automation and Programmability | The impact of automation, controller-based and software-defined networking, REST APIs, configuration management tools and JSON | Two domains deserve special attention. Network Fundamentals is broad and underpins everything else; weak subnetting will cost you points across the whole exam. IP Connectivity is where routing logic lives, and it rewards genuine understanding over memorization. Note: This plan follows the structure of the domains rather than any specific weighting. Check Cisco's official exam topics page and spend proportionally more time on the domains it weights most heavily. ## Choosing your study resources You do not need ten resources. You need a small, complementary set and the discipline to finish them. A strong toolkit looks like this: - One primary text. An official certification guide or an equivalent comprehensive book that maps to the current blueprint. This is your reference for depth. - One video course. Video is excellent for first exposure to a topic and for seeing configuration in action. Pick one reputable course and stick with it. - A lab environment. Cisco Packet Tracer is free and handles most CCNA labs. Cisco Modeling Labs, GNS3 or EVE-NG add real images. Our guide to building a home network lab compares the options. - Flashcards. A spaced repetition app is ideal for port numbers, command syntax, administrative distances and other facts that must be instantly recalled. - Practice exams. Use a reputable practice exam product in the final weeks to measure readiness and find weak areas. Avoid "brain dumps," which violate Cisco's exam agreement and teach you nothing useful. ## The daily and weekly routine A repeatable routine removes the daily decision of "what should I study?" and keeps momentum through the tougher weeks. Here is a structure that works well: ### Weekday sessions (about 60–90 minutes) - Warm-up (10 minutes). Review flashcards and solve two or three subnetting problems. - Learn (30–40 minutes). Read a chapter section or watch the related videos for the week's topic. - Lab (20–30 minutes). Immediately configure what you just learned, then verify it with show commands. - Capture (5 minutes). Write down new commands and anything confusing, and turn key facts into flashcards. ### Weekend session (about 3–4 hours) - Build a larger lab that combines the week's topics with earlier ones. - Break it deliberately and troubleshoot it without looking at your notes. - Review the week's notes and answer practice questions on the topics. - Re-read any section you could not explain clearly in your own words. Pro tip: Try to explain each week's topic out loud as if teaching a colleague. If you stumble, you have found exactly what to review. This technique exposes gaps far faster than re-reading. ## The 90-day plan, week by week The table below is the heart of the plan. Each week has a domain focus, the specific topics to study, a lab focus and a milestone that tells you whether you are ready to move on. Week 13 covers the final days before the exam. Week | Domain focus | Topics | Lab focus | Milestone | 1 | Network Fundamentals | OSI and TCP/IP models, network components, topology architectures, cabling, interface errors, TCP vs. UDP | Basic device setup: hostname, passwords, banners, interface descriptions, saving configs | Navigate the IOS CLI modes comfortably | 2 | Network Fundamentals | Binary, IPv4 addressing, subnet masks, CIDR, private addressing, VLSM | Address a small multi-subnet network and verify connectivity | Subnet any /24 to /30 accurately in your head | 3 | Network Fundamentals | IPv6 addressing, address types, EUI-64, verifying IP settings on client operating systems, virtualization basics | Dual-stack a small network with static IPv6 addresses | Identify IPv6 address types at a glance | 4 | Network Access | Switching concepts, MAC learning, VLANs, access ports, voice VLANs, 802.1Q trunks, native VLAN, CDP and LLDP | Multi-switch VLAN network with trunks | Troubleshoot a broken trunk using show commands | 5 | Network Access | Rapid PVST+, root bridge election, port roles and states, PortFast, BPDU Guard, EtherChannel with LACP | Manipulate the root bridge; build and verify an EtherChannel | Predict which ports will block in a triangle topology | 6 | Network Access and Fundamentals | Wireless principles, RF basics, wireless architectures, AP modes, WLC connectivity, management access methods | Wireless controller and WLAN configuration in a simulator | Explain how an AP, WLC and switch ports work together | 7 | IP Connectivity | Routing table components, longest prefix match, administrative distance, metrics, IPv4 and IPv6 static, default and floating static routes | Three-router static routing lab with a floating backup route | Read a routing table and predict the forwarding decision | 8 | IP Connectivity | Single-area OSPFv2, router ID, neighbor adjacencies, DR and BDR, point-to-point networks, first hop redundancy concepts | OSPF network with broadcast and point-to-point links | Fix OSPF adjacency problems from show output alone | 9 | IP Services | Static NAT, NAT pools and PAT, DHCP server and relay, DNS, NTP, SNMP, syslog, QoS concepts, SSH, TFTP and FTP | Branch router with PAT, DHCP, NTP, syslog and SSH | Internet access from all VLANs through PAT | 10 | Security Fundamentals | Threats and mitigations, device hardening, passwords and MFA, AAA, VPN concepts, standard and extended ACLs, port security, DHCP snooping, DAI, wireless security | ACLs between VLANs; port security and DHCP snooping on access ports | Write and place an extended ACL correctly the first time | 11 | Automation and Programmability | Traditional vs. controller-based networking, SDN architecture, REST APIs, JSON, configuration management tools, other topics listed in the current blueprint | Read and edit JSON; make an API call to a sandbox or lab device | Explain control, data and management planes clearly | 12 | All domains | Full-length practice exams, targeted remediation of weak areas, flashcard review | Build a complete network from a blank config with no notes | Consistently strong practice scores across every domain | 13 | Final review | Light review, subnetting drills, command syntax, rest before exam day | Short troubleshooting drills only | Sit the exam | ## How the phases fit together The thirteen weeks fall naturally into four phases. Understanding the purpose of each phase helps you decide when to push on and when to slow down. ### Phase 1: Foundations (weeks 1–3) This phase is about addressing and models. It is tempting to rush it because the topics feel basic, but every later topic depends on it. The key output is subnetting fluency. If you cannot yet find the network, broadcast and host range for any address quickly, keep drilling with our step-by-step subnetting guide before you move on. Five minutes of subnetting practice every day for the rest of the plan will keep the skill sharp. ### Phase 2: Switching and routing (weeks 4–8) This is the core of the CCNA and where most of your lab time should go. VLANs and trunks lead into spanning tree and EtherChannel, then wireless, static routing and OSPF. The most common stall point is spanning tree, because it requires you to reason about a topology rather than recall facts. Draw every topology, mark the root bridge, root ports, designated ports and blocked ports by hand, then confirm your predictions in the lab. For extra depth on Layer 2 design, read our article on VLANs, trunking and inter-VLAN routing, and for routing, our OSPF fundamentals guide goes beyond the exam minimum. ### Phase 3: Services, security and automation (weeks 9–11) These domains contain many smaller topics, so the risk shifts from conceptual difficulty to breadth. Build a single "branch office" lab and keep adding to it: NAT, DHCP, NTP, syslog, SSH, ACLs and Layer 2 security. Seeing how services interact, for example how an ACL can accidentally block DHCP relay, is excellent exam preparation. For automation, focus on concepts and reading structured data. You will not be asked to write complex programs, but you should be comfortable with JSON, HTTP methods and how controllers differ from device-by-device management. Our network automation guide is a good primer if you want to go further. ### Phase 4: Review and exam (weeks 12–13) This phase converts knowledge into exam performance. Take a full-length practice exam under timed conditions at the start of week 12. Analyze every wrong answer and every lucky guess, then spend the rest of the week fixing those specific weaknesses in the lab and the book. Take a second practice exam at the end of the week to measure progress. Week 13 is for light review and rest, not cramming new material. ## Labs that matter most If you only have time for a limited number of labs, prioritize the ones that combine multiple topics and force you to troubleshoot. These cover a large share of the hands-on skills the exam expects: - Multi-VLAN campus: two access switches and a distribution switch with VLANs, 802.1Q trunks, a deliberately chosen root bridge, an LACP EtherChannel, and SVIs for inter-VLAN routing. - Router-on-a-stick branch: a router with subinterfaces for three VLANs, DHCP for each VLAN and PAT to an "internet" router. - OSPF triangle: three routers running single-area OSPFv2 with loopbacks, manually set router IDs and one broadcast segment where you control the DR election. - Static and floating routes: a primary path and a backup static route with a higher administrative distance that takes over when you shut the primary link. - Secure access layer: port security, DHCP snooping, dynamic ARP inspection, SSH-only management with local or AAA authentication, and an extended ACL protecting a server VLAN. - Dual-stack network: IPv6 addressing on all interfaces with static IPv6 routes, verified with ping and traceroute. For every lab, follow the same rhythm: build it, verify it, document it, break it, fix it. The "break it" step is where most of the learning happens. Watch out: Copying configurations from a lab guide feels productive but builds very little skill. Read the objective, close the guide, and configure from memory. Check the guide only when you are truly stuck, then rebuild the lab from scratch the next day. ## Final weeks and exam day How you handle the last two weeks often decides the result. Prioritize sleep, steady review and confidence-building practice over panic-driven cramming. ### Signs you are ready - You score consistently well on reputable practice exams across all six domains, not just overall. - You can subnet quickly and accurately without a calculator. - You can build the multi-VLAN and OSPF labs from a blank configuration and troubleshoot them using show commands. - You can explain why, not just what, for topics like spanning tree port roles, OSPF DR election and administrative distance. ### On exam day - Know the logistics. Cisco exams are delivered by Pearson VUE, either at a test center or online with remote proctoring. Read the identification and check-in requirements in your confirmation well in advance. - Manage your time. Note the total time and number of questions at the start and check your pace periodically. Do not let one difficult simulation consume a disproportionate share of the clock. - Answer every question. Cisco exams generally do not let you return to earlier questions, so make your best decision and move on. - Read carefully. Watch for words like "not," "best" and "most likely," and check whether a question asks for one answer or several. - Use your scratch space. Write out subnet calculations rather than doing them in your head under pressure. ## Common pitfalls and how to avoid them - Too many resources. Jumping between books and courses creates the illusion of progress. Choose one primary text and one course and finish them. - Reading without labbing. If you have not configured it, you do not really know it. Every topic in the plan has a lab for a reason. - Skipping review. Without spaced repetition, the material from week 2 will be fuzzy by week 10. Keep up with your flashcards daily. - Ignoring weak domains. It is more enjoyable to practice what you already know. Practice exam results tell you where to spend time; listen to them. - Studying alone with no feedback. A study partner, community or mentor catches misunderstandings you would never notice yourself. - Letting a bad week end the plan. Missing a few days is normal. Pick up where you left off and adjust the schedule rather than starting over. ## Key takeaways - Ninety days is realistic for many candidates at around eight to twelve hours of study per week; extend phases where needed rather than rushing. - Use the official CCNA 200-301 exam topics as your master checklist and confirm the current version and weighting before you begin. - Keep resources focused: one primary text, one video course, a lab platform, flashcards and a reputable practice exam product. - Follow a consistent routine of learn, lab, review, with a longer combined lab every weekend. - Invest heavily in the foundations, especially subnetting, and in hands-on switching and routing labs. - Use timed practice exams in the final phase to find and fix weaknesses, then rest before exam day. A plan is only as good as your ability to stick to it, and having someone check your progress makes a big difference. If you want structured accountability, lab reviews and answers to your questions as you go, our 1:1 CCNA Mentorship Program pairs this approach with eight weeks of personal guidance. Have a question about your own timeline? Get in touch. ## FAQ Q: Is 90 days enough to pass the CCNA? A: For many candidates, yes, especially those with some IT or networking experience who can study consistently for roughly eight to twelve hours per week. Complete beginners or people with less time may need longer. The plan works best as a structure; extend any phase where your practice results show gaps rather than rushing to the exam date. Q: Which CCNA exam domains are covered in this plan? A: The plan follows the six domains of the CCNA 200-301 blueprint: Network Fundamentals, Network Access, IP Connectivity, IP Services, Security Fundamentals, and Automation and Programmability. Always check Cisco's official exam topics page for the current version and weighting before you begin, because blueprints are updated periodically. Q: Do I need physical Cisco equipment to study for the CCNA? A: No. Cisco Packet Tracer is free and covers most CCNA labs, and emulators such as Cisco Modeling Labs, GNS3 or EVE-NG let you run real images. Physical equipment is useful but optional. What matters is that you configure and troubleshoot every topic hands-on rather than only reading about it. Q: How many hours a day should I study for the CCNA? A: Consistency matters more than intensity. Around one to two hours on weekdays plus a longer lab session at the weekend works well for most people with a full-time job. Short daily sessions with regular review beat occasional marathon sessions because they give your memory time to consolidate. Q: When am I ready to book the CCNA exam? A: Good signs are consistently strong scores on reputable practice exams across all domains, the ability to subnet quickly and accurately without a calculator, and being able to build and troubleshoot a multi-VLAN, multi-router lab with OSPF, NAT, DHCP and ACLs from a blank configuration. Many candidates book a date early for motivation and adjust it if needed. --- # OSPF Fundamentals: Areas, LSAs, Neighbor States and Configuration URL: https://roadtoneteng.com/ospf-fundamentals/ Updated: 2026-10-14 Open Shortest Path First (OSPF) is the interior gateway protocol you are most likely to meet in an enterprise network, a branch WAN or a data center underlay. It is an open standard, every serious vendor implements it, and it punishes guesswork: a mismatched timer or an MTU difference can leave you staring at neighbors that never reach FULL. This guide walks through OSPF fundamentals the way you will actually use them: how the link-state database works, what areas and LSA types are for, how neighbors form, how the DR and BDR are elected, and how to write a clean Cisco IOS configuration you can verify with confidence. ## How OSPF works: link-state routing in plain terms OSPF version 2 is defined in RFC 2328 and carries IPv4 routes. OSPFv3, defined in RFC 5340, was built for IPv6 and can also carry IPv4 with address families. Both run directly over IP using protocol number 89, not over TCP or UDP. That detail matters when you write firewall rules or ACLs on links between routers. Distance-vector protocols such as RIP tell their neighbors "here are the networks I know and how far away they are." Link-state protocols work differently. Every OSPF router describes its own links, their state and their cost in small records called Link-State Advertisements (LSAs). Those LSAs are flooded to every router in the area, so every router ends up with an identical copy of the link-state database (LSDB). Each router then runs Dijkstra's Shortest Path First (SPF) algorithm against that database, with itself as the root, to build a loop-free tree of best paths. The results go into the routing table with an administrative distance of 110. The practical consequences are worth remembering: - Every router in an area has the same map, so routing decisions are consistent and loops are avoided by design. - A change in one place triggers flooding and an SPF run on every router in the area. Large, flat areas therefore cost CPU and memory, which is why areas exist. - OSPF metrics are cost, derived from interface bandwidth, not hop count. ### OSPF packet types OSPF uses five packet types. You will see them in debugs and packet captures, so it pays to know them by name: - Hello discovers neighbors, checks that parameters match and acts as a keepalive. - Database Description (DBD or DD) summarizes the contents of the LSDB during adjacency formation. - Link-State Request (LSR) asks a neighbor for specific LSAs that are missing or out of date. - Link-State Update (LSU) carries the actual LSAs. - Link-State Acknowledgment (LSAck) confirms that LSAs were received, because OSPF provides its own reliability. Hellos go to the multicast address 224.0.0.5 (AllSPFRouters). On broadcast networks, updates sent toward the designated routers use 224.0.0.6 (AllDRouters). On broadcast and point-to-point networks the default hello interval is 10 seconds and the dead interval is 40 seconds; on NBMA networks the defaults are 30 and 120. ### Cost and reference bandwidth Cisco calculates cost as reference bandwidth divided by interface bandwidth, with a default reference of 100 Mbps. That means FastEthernet, 1 Gbps and 10 Gbps links all get a cost of 1. Fix it on day one with auto-cost reference-bandwidth (in Mbps), using the same value on every router. Interface speed | Cost with default reference (100 Mbps) | Cost with reference 100000 (100 Gbps) | 100 Mbps | 1 | 1000 | 1 Gbps | 1 | 100 | 10 Gbps | 1 | 10 | 40 Gbps | 1 | 2 | 100 Gbps | 1 | 1 | ## OSPF areas and router roles An area is a group of routers and links that share the same LSDB. Areas contain the cost of flooding and SPF: a link flapping in area 10 triggers a full SPF run only inside area 10. Other areas receive a summarized view and do much less work. OSPF uses a two-level hierarchy. Area 0, the backbone, sits in the middle, and every other area must attach to it. Inter-area traffic passes through the backbone, which is also what prevents inter-area routing loops. If an area cannot physically touch area 0, a virtual link can patch it through a transit area, but treat that as a temporary fix rather than a design. ### Router roles - Internal router: all interfaces in a single area. - Backbone router: at least one interface in area 0. - Area Border Router (ABR): interfaces in area 0 and at least one other area. ABRs keep a separate LSDB per area and are where inter-area summarization happens. - Autonomous System Boundary Router (ASBR): redistributes external routes into OSPF, for example static routes, a default route from an ISP, or routes from BGP or EIGRP. ### Area types Special area types reduce the number of LSAs an area has to carry, which is useful for branch sites with a single exit: Area type | Blocks | Gets instead | Typical use | Standard (normal) | Nothing | Full intra-area, inter-area and external routes | Default for most areas | Stub | Type 5 (and type 4) | Default route from the ABR as a type 3 | Branches with one exit, no local redistribution | Totally stubby (Cisco) | Types 3, 4 and 5 | Only a default route from the ABR | Small branches that need nothing but a way out | Not-So-Stubby Area (NSSA) | Type 5 | Local externals as type 7, translated to type 5 at the ABR | Stub-like site that must redistribute something local | Totally NSSA | Types 3, 4 and 5 | Default route plus local type 7 externals | Small site with a local external connection | Pro tip: For small and mid-sized networks, a single area 0 is usually the right answer. Modern routers handle a few hundred routers in one area without breaking a sweat. Add areas when you have a real reason (unstable remote links, many branches, a need to summarize), not because the textbook shows four of them. ## LSA types you need to know LSAs are the building blocks of the database. Each type describes something different and is flooded with a different scope. When you run show ip ospf database, the output is grouped by these types, so reading it fluently is a core troubleshooting skill. Type | Name | Generated by | Flooding scope | Describes | 1 | Router LSA | Every router | Within its area | The router's own links, their states and costs | 2 | Network LSA | The DR on a multi-access segment | Within its area | The transit network and all routers attached to it | 3 | Summary LSA | ABR | Into other areas | Networks from another area (inter-area routes, shown as O IA) | 4 | ASBR Summary LSA | ABR | Into other areas | How to reach an ASBR located in another area | 5 | AS External LSA | ASBR | Entire OSPF domain except stub and NSSA areas | External routes (O E1 or O E2) | 7 | NSSA External LSA | ASBR inside an NSSA | Within the NSSA only | External routes, converted to type 5 by the ABR (O N1 or O N2) | ### E1 versus E2 external routes External routes come in two flavors. E2, the default on Cisco, keeps the metric that was set at redistribution and ignores the internal cost to reach the ASBR. E1 adds the internal cost, which makes it the better choice when you have two ASBRs advertising the same prefix and you want each router to use the closer one. When both exist for the same prefix, OSPF prefers E1 over E2 regardless of metric. ## OSPF neighbor states and adjacency formation Two routers do not simply "become neighbors." They walk through a defined state machine, and knowing where a pair is stuck tells you almost exactly what is wrong. State | What is happening | If it is stuck here, check | Down | No hellos received from the neighbor within the dead interval | Physical link, interface shutdown, ACLs blocking protocol 89, passive interface | Attempt | NBMA only: the router is sending unicast hellos to a configured neighbor | The neighbor statement and reachability on Frame Relay-style networks | Init | A hello was received, but it does not list this router's ID yet | One-way communication, ACL or filter on one side, multicast problems | 2-Way | Both routers see each other in hellos; DR/BDR election happens here | Normal for DROTHER to DROTHER on broadcast segments | ExStart | Routers negotiate master/slave and the starting DBD sequence number | MTU mismatch, duplicate router IDs | Exchange | Routers exchange DBD packets that summarize their databases | MTU mismatch (very common), packet loss | Loading | Routers request and receive missing LSAs with LSR and LSU packets | Corrupted or very large LSAs, packet loss | Full | Databases are synchronized; the adjacency is complete | Nothing, this is the goal | ### Parameters that must match Before two routers move beyond Init, their hellos must agree on several values. If any of these differ, the neighbor never forms and IOS will usually tell you why in debug ip ospf adj or the log: - Area ID, and the area type flags (stub, NSSA) for that area - Subnet and subnet mask on broadcast and NBMA networks - Hello and dead intervals - Authentication type and key - Unique router IDs (duplicates cause flapping and odd database behavior) - Compatible network types, for example both point-to-point or both broadcast MTU is not checked in the hello, but it is checked in DBD packets, which is why an MTU mismatch shows up later as a neighbor stuck in ExStart or Exchange. If you need a refresher on matching masks and subnet boundaries, the guide to subnetting made simple covers the math. Watch out: The command ip ospf mtu-ignore will bring a stuck adjacency to FULL, but it hides a real problem. Large LSUs can still be dropped or fragmented later. Fix the MTU on the interfaces instead. ## DR and BDR election On a multi-access segment such as an Ethernet VLAN with five routers, a full mesh of adjacencies would mean ten adjacencies and a lot of duplicate flooding. OSPF avoids this by electing a Designated Router (DR) and a Backup Designated Router (BDR). Every other router, called a DROTHER, forms a FULL adjacency only with the DR and BDR. DROTHERs send updates to 224.0.0.6, and the DR re-floods them to everyone on 224.0.0.5. The DR also generates the type 2 network LSA for the segment. ### Election rules - The router with the highest OSPF interface priority wins. The default is 1, the range is 0 to 255, and a priority of 0 means the router will never become DR or BDR. - If priorities tie, the highest router ID wins. - The election is non-preemptive. If a better router boots later, it does not take over. The current DR keeps the role until it fails, at which point the BDR is promoted and a new BDR is elected. Because the election is non-preemptive, the router that boots first often becomes DR. To make a specific core router the DR, raise its priority, set priority 0 on routers that should never be DR, and clear the OSPF process during a maintenance window to force a fresh election. Set router IDs manually too, so the tie-breaker is predictable. On a link that only ever has two routers, such as a routed uplink between a core switch and a distribution switch, skip the election entirely by setting the network type to point-to-point. Adjacencies form faster, there is no type 2 LSA, and the database is smaller. ``` R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DR 00:00:36 10.0.0.2 GigabitEthernet0/1 3.3.3.3 1 FULL/BDR 00:00:33 10.0.0.3 GigabitEthernet0/1 4.4.4.4 1 2WAY/DROTHER 00:00:38 10.0.0.4 GigabitEthernet0/1 ``` In this output R1 is itself a DROTHER. It is FULL with the DR and BDR and sits in 2-Way with the other DROTHER, which is exactly what you want to see. ## Configuring OSPF on Cisco IOS Here is a practical two-area example. R1 is an ABR with an uplink in area 0 and a user LAN in area 1. The configuration uses a fixed router ID, a sensible reference bandwidth, passive interfaces by default, and point-to-point network type on the router-to-router link. ``` interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface GigabitEthernet0/0 description Uplink to CORE-R2 (area 0) ip address 10.0.12.1 255.255.255.252 ip ospf network point-to-point ! interface GigabitEthernet0/1 description Users VLAN (area 1) ip address 192.168.10.1 255.255.255.0 ! router ospf 1 router-id 1.1.1.1 auto-cost reference-bandwidth 100000 passive-interface default no passive-interface GigabitEthernet0/0 network 1.1.1.1 0.0.0.0 area 0 network 10.0.12.0 0.0.0.3 area 0 network 192.168.10.0 0.0.0.255 area 1 area 1 range 192.168.8.0 255.255.252.0 ``` A few notes on this configuration: - The process ID (1) is locally significant. Neighbors do not need matching process IDs. - The network command uses a wildcard mask and does not advertise a network directly. It enables OSPF on any interface whose address matches, and OSPF then advertises that interface's subnet. - passive-interface default stops hellos on every interface, then you re-enable only the links where you expect neighbors. The user VLAN is still advertised, but no one on that VLAN can form an adjacency with your router. - area 1 range on the ABR summarizes area 1 subnets 192.168.8.0 through 192.168.11.255 into a single type 3 LSA toward area 0. ### Interface-level configuration Many engineers prefer enabling OSPF directly on the interface. It is explicit and easier to read in a running configuration: ``` interface GigabitEthernet0/0 ip ospf 1 area 0 ! interface GigabitEthernet0/1 ip ospf 1 area 1 ``` ### Authentication Always authenticate OSPF on links you do not fully control. Classic MD5 authentication is widely supported; newer IOS XE releases also support HMAC-SHA authentication through key chains (RFC 5709), which you should prefer where every router supports it. ``` key chain OSPF-KEYS key 1 key-string Str0ngSharedSecret cryptographic-algorithm hmac-sha-256 ! interface GigabitEthernet0/0 ip ospf authentication key-chain OSPF-KEYS ``` ### Default route and stub areas An edge router that has a static default route toward the internet can inject it into OSPF with default-information originate. Add the always keyword only if you want the default advertised even when the router has no default route itself. To make area 2 totally stubby, configure area 2 stub on every router in the area and add area 2 stub no-summary on the ABR. ``` ip route 0.0.0.0 0.0.0.0 203.0.113.1 ! router ospf 1 default-information originate area 2 stub no-summary ``` If you want to practice all of this without touching production, a virtual topology in a home network lab is the fastest way to break and fix adjacencies safely. ## Verifying and troubleshooting OSPF A configuration you have not verified is only a hypothesis. These are the commands you will use most, in roughly the order you will use them: ``` show ip ospf interface brief show ip ospf neighbor show ip ospf interface GigabitEthernet0/0 show ip ospf database show ip ospf database router 2.2.2.2 show ip route ospf show ip protocols debug ip ospf adj ``` - show ip ospf interface brief confirms which interfaces are running OSPF, in which area, their cost, state (DR, BDR, DROTHER, P2P) and neighbor count. If an interface is missing here, your network statement or interface command did not match. - show ip ospf interface shows timers, network type, priority and whether the interface is passive. - show ip ospf database tells you whether LSAs are actually arriving. If a route is missing from the routing table but its LSA is present, look at SPF, summarization or a distribute-list. If the LSA is missing, look at flooding, area design or filtering at the ABR. - show ip route ospf shows codes O (intra-area), O IA (inter-area), O E1 and O E2 (external), and O N1 and O N2 (NSSA external). ### A repeatable checklist for a missing neighbor - Is the interface up/up and can you ping the neighbor's interface address? - Is OSPF enabled on the interface, and is it not passive? - Do area IDs, subnet masks, timers, network types and authentication match? - Is an ACL or firewall dropping IP protocol 89 or the 224.0.0.5 multicast? - If the neighbor is stuck in ExStart or Exchange, compare the IP MTU on both sides. - Are the router IDs unique across the domain? This is a direct application of the bottom-up approach described in the structured network troubleshooting methodology: prove the lower layers before blaming the protocol. Note: Log adjacency changes with log-adjacency-changes detail under the OSPF process and send them to a syslog server. A neighbor that flaps every few hours is easy to miss in the console but obvious in a centralized log, as explained in Network Monitoring 101. ## OSPF design best practices Most OSPF problems in production are design problems. A handful of habits prevents most of them: - Keep it simple. Start with a single area 0 and add areas when the network grows or when you need to isolate unstable links. - Use loopbacks and fixed router IDs. Loopbacks never go down, so management and BGP peering stay stable, and fixed IDs make every output readable. - Plan your addressing for summarization. Give each area a contiguous block so the ABR can advertise one summary instead of dozens of subnets. This is where good IP planning pays off. - Use point-to-point network type on any link with exactly two routers. - Make passive the default and only enable hellos where you expect neighbors. - Authenticate every adjacency, ideally with SHA-based key chains. - Set the reference bandwidth consistently across every router before you go live. - Document areas, router IDs and costs alongside your diagrams so the next engineer does not have to reverse-engineer the design. If you are on the path from administering networks to engineering them, OSPF is one of the first protocols where design decisions start to matter more than syntax. When your network needs to reach the internet over more than one provider, the next step is BGP basics for network admins. ## Key takeaways - OSPF is a link-state protocol (RFC 2328 for OSPFv2) running over IP protocol 89, with an administrative distance of 110 and a cost-based metric. - Areas contain flooding and SPF work; every area must connect to area 0, and many networks are best served by a single area. - Type 1 and 2 LSAs describe an area, type 3 and 4 cross area boundaries, and type 5 and 7 carry external routes. - Neighbors walk through Down, Init, 2-Way, ExStart, Exchange, Loading and Full; the state where they stop points to the cause. - DR/BDR election uses priority, then router ID, and is non-preemptive. Use point-to-point network type on two-router links. - Set router IDs, reference bandwidth, passive interfaces and authentication deliberately, then verify with show commands before you call it done. Want a second set of eyes on your routing design, or a clear picture of how OSPF is really behaving in your network today? A Network Health Assessment reviews your routing, adjacencies and redundancy and gives you a prioritized fix list. If you are studying for your certification, the 1:1 CCNA Mentorship Program covers OSPF hands-on, lab by lab. Questions about your specific setup? Get in touch. ## FAQ Q: Why is my OSPF neighbor stuck in EXSTART or EXCHANGE? A: The most common cause is an MTU mismatch between the two interfaces. The router with the smaller MTU cannot accept the larger database description packets, so the exchange never completes. Match the IP MTU on both sides rather than relying on ip ospf mtu-ignore. Q: Is a neighbor in 2WAY/DROTHER state a problem? A: No. On a broadcast segment such as Ethernet, routers that are neither DR nor BDR only form full adjacencies with the DR and BDR. Between two DROTHER routers, 2-Way is the expected, stable state. Q: How is the OSPF router ID chosen? A: A manually configured router-id always wins. Without it, IOS uses the highest IPv4 address on an up loopback interface, and if there are no loopbacks, the highest IPv4 address on an active physical interface. The router ID is only re-evaluated when the OSPF process restarts. Q: What does area 0 do and do I always need it? A: Area 0 is the backbone. In a multi-area design every other area must connect to area 0, because inter-area routes are passed through the backbone. A single-area network can run entirely in area 0, which is the simplest choice for small and mid-sized networks. Q: Should I change the OSPF reference bandwidth? A: Yes, on any network with links faster than 100 Mbps. The default reference of 100 Mbps gives Fast Ethernet, Gigabit and 10 Gigabit links the same cost of 1. Set auto-cost reference-bandwidth to a value at least as large as your fastest link, and set it identically on every OSPF router. --- # BGP Basics for Network Admins: How the Internet Really Routes URL: https://roadtoneteng.com/bgp-basics-for-network-admins/ Updated: 2026-10-14 Border Gateway Protocol (BGP) is the routing protocol of the internet. Every ISP, cloud provider and content network uses it to tell the rest of the world which IP prefixes it can reach. For many network admins, BGP stays invisible until the day the business buys a second internet circuit, gets its own address block or connects to a cloud provider. Then it suddenly matters a great deal. This guide covers BGP basics the practical way: what makes BGP different from an IGP, how eBGP and iBGP behave, which path attributes drive decisions, how the best-path algorithm works, and how to build a safe dual-ISP configuration on Cisco IOS. ## What BGP is and why it is different BGP version 4 is defined in RFC 4271. It is a path-vector protocol: instead of advertising a cost, each route carries a list of the autonomous systems it has passed through. An autonomous system (AS) is a network under a single administrative routing policy, identified by an AS number (ASN). If a router sees its own ASN in an incoming AS path, it rejects the route. That is how BGP prevents loops across thousands of independent networks. Compared with an interior protocol such as OSPF, BGP has a very different personality: - It runs over TCP port 179. Neighbors (peers) are configured explicitly; there is no automatic discovery. - It is policy-driven, not speed-driven. BGP does not care about bandwidth or latency by default. It chooses paths based on attributes you can manipulate to express business intent. - It scales to enormous tables. The full IPv4 internet table is on the order of a million prefixes, far beyond what any IGP is meant to carry. - It converges deliberately. BGP is stable and conservative rather than fast. Timers and dampening favor stability over instant reaction. If OSPF is new to you as well, read OSPF fundamentals first. In real networks, the IGP and BGP work together: the IGP provides reachability inside your network, and BGP carries external and policy-rich routes on top of it. ### AS numbers Original ASNs were 16-bit values (1 to 65535). Because they ran short, 32-bit ASNs were introduced (now RFC 6793), raising the range to over four billion. Some ranges are reserved: Range | Purpose | 64496 to 64511 and 65536 to 65551 | Documentation and examples (RFC 5398) | 64512 to 65534 | Private use, 16-bit (RFC 6996) | 4200000000 to 4294967294 | Private use, 32-bit (RFC 6996) | 23456 | AS_TRANS, a placeholder for 32-bit ASNs toward older speakers | Public ASNs are assigned by regional internet registries such as ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC. The examples in this article use documentation ASNs and documentation address blocks from RFC 5737. ## BGP sessions, messages and neighbor states A BGP session is a TCP connection between two configured peers. Once it is up, BGP exchanges four core message types: - OPEN starts the session and negotiates the ASN, hold time, router ID and capabilities such as 32-bit ASNs and address families. - UPDATE advertises new routes with their attributes or withdraws routes that are no longer reachable. - KEEPALIVE keeps the session alive. Cisco defaults to a 60-second keepalive and a 180-second hold time. - NOTIFICATION reports an error and closes the session. A fifth type, ROUTE-REFRESH (RFC 2918), lets a router ask a peer to resend its routes so new inbound policy can be applied without tearing the session down. State | Meaning | Idle | BGP is not trying to connect, either by configuration or after an error | Connect | Waiting for the TCP three-way handshake to complete | Active | The TCP attempt failed; the router is retrying. Despite the name, this is not good | OpenSent | TCP is up and an OPEN message was sent | OpenConfirm | OPEN received and accepted; waiting for a KEEPALIVE | Established | The session is up and UPDATEs can flow | In show ip bgp summary, an established neighbor shows a number (prefixes received) in the State/PfxRcd column. Anything else, such as Idle or Active, means the session is down. ## eBGP vs iBGP The same protocol behaves differently depending on whether the peer is in another AS or in yours. Behavior | eBGP | iBGP | Peers are in | Different autonomous systems | The same autonomous system | Administrative distance (Cisco) | 20 | 200 | Default TTL | 1 (peers must be directly connected unless you configure multihop) | 255 (peers are usually loopbacks reached via the IGP) | AS_PATH on advertisement | Prepends its own ASN | Unchanged | NEXT_HOP on advertisement | Set to itself | Unchanged unless next-hop-self is configured | Re-advertising learned routes | To all peers | Not to other iBGP peers (iBGP split horizon) | The iBGP split-horizon rule is the one that surprises people. Because the AS path does not change inside an AS, BGP cannot use it to detect internal loops, so a route learned from one iBGP peer is never passed to another iBGP peer. The classic consequence is that iBGP requires a full mesh of sessions. With n routers, that means n(n-1)/2 sessions, which becomes unmanageable quickly. Larger networks solve this with route reflectors (RFC 4456) or, less commonly, confederations (RFC 5065). Watch out: When an edge router learns a route from its ISP and passes it to an internal iBGP peer, the next hop is still the ISP's address. If the internal router cannot reach that address through the IGP, the route is unusable. Configure next-hop-self toward iBGP peers on your edge routers, or advertise the ISP link subnet into your IGP. ## BGP path attributes Every BGP route carries attributes. They fall into four categories defined by the standard, plus one Cisco-specific value: Attribute | Category | What it does | Preference | Weight | Cisco proprietary, local to the router | Influences outbound path choice on a single router | Higher wins (default 0, or 32768 for local routes) | LOCAL_PREF | Well-known discretionary | Influences outbound path choice across the whole AS; shared with iBGP peers only | Higher wins (default 100) | AS_PATH | Well-known mandatory | List of ASNs the route has traversed; used for loop prevention | Shorter wins | ORIGIN | Well-known mandatory | How the route entered BGP: IGP (i), EGP (e) or incomplete (?) | IGP < EGP < incomplete | NEXT_HOP | Well-known mandatory | IP address to forward traffic to | Must be reachable | MED (MULTI_EXIT_DISC) | Optional non-transitive | Suggests to a neighboring AS which entry point to use | Lower wins | COMMUNITY | Optional transitive | Tags routes so policy can act on them, for example to ask an ISP to lower preference | No inherent preference | A simple rule of thumb helps here: you control outbound traffic with LOCAL_PREF (and weight on a single router), and you influence inbound traffic with AS_PATH prepending, MED and communities. Inbound influence is always a request, because the other networks make the final decision. ## The BGP best-path selection order When BGP has several paths to the same prefix, it compares them step by step and stops at the first difference. The Cisco IOS order is: - Ignore paths whose NEXT_HOP is unreachable. - Prefer the highest weight. - Prefer the highest LOCAL_PREF. - Prefer paths originated locally by this router (network, aggregate or redistribution). - Prefer the shortest AS_PATH. - Prefer the lowest ORIGIN type: IGP, then EGP, then incomplete. - Prefer the lowest MED (by default compared only between paths from the same neighboring AS). - Prefer eBGP over iBGP paths. - Prefer the path with the lowest IGP metric to the next hop. - If multipath is configured, install equal paths in the routing table. - For eBGP paths, prefer the oldest (most stable) path. - Prefer the path from the neighbor with the lowest BGP router ID. - Prefer the shortest cluster list (route reflection). - Prefer the path from the lowest neighbor address. A popular mnemonic for the first steps is "We Love Oranges AS Oranges Mean Pure Refreshment": Weight, Local preference, Originated, AS path, Origin, MED, Paths (eBGP over iBGP), Router ID. Other vendors follow the same logic but may skip weight or differ in tie-breakers, so check your platform's documentation. Pro tip: Run show ip bgp 203.0.113.0/24 to see every path for one prefix, its attributes and which one is marked "best." When a path is not chosen, compare the attributes in the order above and you will find the reason in seconds. ## A practical dual-ISP configuration on Cisco IOS Here is the most common reason a small or mid-sized business runs BGP: one edge router, two ISPs, and its own /24. In this example your network is AS 64496 with prefix 203.0.113.0/24. ISP-A is AS 64500 and ISP-B is AS 64510. The goal is to send outbound traffic through ISP-A, keep ISP-B as a working backup, and accept only a default route from each provider instead of the full table. ``` ip route 203.0.113.0 255.255.255.0 Null0 254 ! ip prefix-list OUR-PREFIXES seq 10 permit 203.0.113.0/24 ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0 ! route-map ISP-A-IN permit 10 match ip address prefix-list DEFAULT-ONLY set local-preference 200 ! route-map ISP-B-IN permit 10 match ip address prefix-list DEFAULT-ONLY set local-preference 100 ! route-map ISP-A-OUT permit 10 match ip address prefix-list OUR-PREFIXES ! route-map ISP-B-OUT permit 10 match ip address prefix-list OUR-PREFIXES set as-path prepend 64496 64496 64496 ! router bgp 64496 bgp router-id 192.0.2.2 bgp log-neighbor-changes neighbor 192.0.2.1 remote-as 64500 neighbor 192.0.2.1 description ISP-A neighbor 192.0.2.1 password Use-A-Long-Secret-1 neighbor 198.51.100.1 remote-as 64510 neighbor 198.51.100.1 description ISP-B neighbor 198.51.100.1 password Use-A-Long-Secret-2 ! address-family ipv4 unicast network 203.0.113.0 mask 255.255.255.0 neighbor 192.0.2.1 activate neighbor 192.0.2.1 route-map ISP-A-IN in neighbor 192.0.2.1 route-map ISP-A-OUT out neighbor 192.0.2.1 maximum-prefix 10 neighbor 198.51.100.1 activate neighbor 198.51.100.1 route-map ISP-B-IN in neighbor 198.51.100.1 route-map ISP-B-OUT out neighbor 198.51.100.1 maximum-prefix 10 exit-address-family ``` What each piece does: - The Null0 static route exists because the BGP network command only advertises a prefix that matches a route in the routing table exactly. Pointing the aggregate at Null0 keeps the /24 advertised and stable even if internal subnets change, while more specific routes still forward real traffic. - Outbound route-maps with a prefix-list guarantee you only ever advertise your own prefix. Without them, a router that learns routes from ISP-A could re-advertise them to ISP-B and turn your office into a transit network. That mistake has caused real internet outages. - LOCAL_PREF 200 on ISP-A makes it the preferred exit for outbound traffic across your AS. - AS_PATH prepending toward ISP-B makes the path through ISP-B look longer to the rest of the internet, so most inbound traffic arrives through ISP-A. It is a strong hint, not a guarantee. - maximum-prefix protects the router if a provider accidentally sends far more routes than agreed. - The password enables TCP MD5 authentication (RFC 2385) on the session. Agree on the secret with each ISP. Activating each neighbor explicitly under the address family works regardless of whether your IOS release enables IPv4 unicast for new neighbors by default. Also note that some platforms implement RFC 8212 and will not exchange eBGP routes until a policy is applied. Classic IOS does not enforce that, so the filtering above is your responsibility. ### Default route, partial routes or the full table? ISPs typically offer three options. A default route only is the lightest and works well with a single edge router, as in the example above. Partial routes (the provider's own and customer prefixes, plus a default) let you send traffic for those destinations over the most direct provider without much memory cost. The full table gives the most precise outbound path selection, but it demands a router with enough memory and CPU for every internet prefix plus room to grow, and it gives you more to monitor. For most small and mid-sized businesses, default-only or partial routes deliver nearly all of the resilience with a fraction of the operational load. Note: After you change an inbound policy, apply it without dropping the session using clear ip bgp 192.0.2.1 soft in. A hard clear ip bgp * resets every session and briefly takes your internet connectivity down. ## Verifying and troubleshooting BGP ``` show ip bgp summary show ip bgp show ip bgp 0.0.0.0 show ip bgp neighbors 192.0.2.1 show ip bgp neighbors 192.0.2.1 advertised-routes show ip bgp neighbors 192.0.2.1 routes show ip route bgp ``` Most BGP problems fall into a few buckets: - Session stuck in Idle or Active: no IP reachability to the peer, wrong neighbor address or remote-as, TCP 179 blocked by an ACL or firewall, MD5 password mismatch, or a loopback-to-loopback peering missing update-source (and ebgp-multihop for eBGP). - Session up, no routes received: inbound route-map or prefix-list too strict, the ISP is not sending what you expected, or the address family is not activated. - Route received but not best: walk the best-path order. Often an unreachable next hop or an unexpected LOCAL_PREF. - Prefix not reaching the internet: check advertised-routes, confirm the Null0 route exists, and confirm the ISP has your prefix in its filters and in its IRR records. External looking glasses and public route collectors let you see how the rest of the internet sees your prefix, which is the only real proof that inbound traffic engineering works. Pair that with the layered approach from the network troubleshooting methodology guide: prove TCP 179 works before you debug policy. ## RPKI and routing security BGP was designed on trust. Any AS can announce any prefix, and its neighbors will believe it unless they filter. Route leaks and hijacks, whether accidental or malicious, have repeatedly redirected or blackholed traffic for major services. Several layers of protection now exist, and even small networks should understand them. ### Resource Public Key Infrastructure (RPKI) RPKI lets the holder of an address block publish a cryptographically signed Route Origin Authorization (ROA) stating which AS may originate that prefix and up to what prefix length. Routers then perform Route Origin Validation (RFC 6811), classifying each announcement as: - Valid: a ROA exists and the origin AS and prefix length match. - Invalid: a ROA exists but the origin AS or length does not match. Most large networks now drop these. - NotFound: no ROA covers the prefix. Routers usually do not process RPKI data themselves. A separate validator downloads and checks the signed objects, and routers fetch the results using the RPKI-to-Router protocol (RFC 8210). If you hold your own address space, the most valuable step is simple: create ROAs for your prefixes in your RIR portal and keep the maximum length tight. That way networks that validate will reject anyone else announcing your space. ### Other good hygiene - Filter what you send: only your own prefixes, every time. - Filter what you receive: no bogons, no prefixes longer than /24 for IPv4 or /48 for IPv6, and never your own prefix coming back from outside. - Use maximum-prefix limits and session authentication. - Keep IRR (Internet Routing Registry) objects accurate so your providers can build filters automatically. - Review the community-driven MANRS (Mutually Agreed Norms for Routing Security) actions as a checklist. Routing security also belongs in your broader edge protection plan, alongside the controls in the firewall hardening checklist. And if you advertise IPv6 too, the same principles apply; the IPv6 for network admins guide covers the addressing side. ## Key takeaways - BGP-4 (RFC 4271) is a path-vector protocol running over TCP 179, built for policy and scale rather than speed. - eBGP (AD 20) connects different autonomous systems; iBGP (AD 200) distributes external routes inside one AS and needs a full mesh or route reflectors. - Use LOCAL_PREF to control outbound traffic; use AS_PATH prepending, MED and communities to influence inbound traffic. - Learn the best-path order: weight, LOCAL_PREF, locally originated, AS_PATH, origin, MED, eBGP over iBGP, IGP metric, then tie-breakers. - Always filter outbound advertisements to your own prefixes and set maximum-prefix limits. - Create RPKI ROAs for any address space you hold, and filter what you accept from peers. Adding a second ISP or moving to your own address space is a project where small mistakes have public consequences. If you want help designing and validating a resilient internet edge, the Small Business Network Setup service covers dual-ISP design end to end, and Firewall & Security Hardening locks down the edge around it. For anything else, contact us. ## FAQ Q: Do I need BGP if I only have one internet provider? A: Usually not. With a single ISP, a static default route toward the provider is simpler and just as reliable. BGP becomes useful when you have your own provider-independent address space, connect to two or more ISPs, or need to control how traffic enters and leaves your network. Q: What is the difference between eBGP and iBGP? A: eBGP runs between routers in different autonomous systems, typically you and your ISP, and has an administrative distance of 20. iBGP runs between routers inside the same autonomous system, has an administrative distance of 200, does not change the next hop by default, and does not re-advertise iBGP-learned routes to other iBGP peers. Q: Why is my BGP neighbor stuck in Active state? A: Active means the router is trying to open a TCP session on port 179 and failing. Check IP reachability to the neighbor address, the remote-as value, the update-source for loopback peering, ebgp-multihop for non-directly connected eBGP peers, ACLs or firewalls blocking TCP 179, and MD5 password mismatches. Q: Can I use a private AS number with my ISP? A: Many ISPs will peer with a customer using a private ASN (64512 to 65534, or 4200000000 to 4294967294) if you only connect to them and they strip the private ASN before advertising your prefix. To multihome to different providers, you normally need a public ASN from your regional internet registry. Q: What is RPKI and should a small network care? A: RPKI lets address holders publish signed Route Origin Authorizations stating which AS may originate their prefixes. Networks that perform route origin validation can then drop invalid announcements. If you hold your own address space, creating ROAs through your RIR is a small task that protects your prefixes from accidental and malicious hijacks. --- # A Structured Network Troubleshooting Methodology That Saves Hours URL: https://roadtoneteng.com/network-troubleshooting-methodology/ Updated: 2026-10-14 Every network admin has lived through the same afternoon: something is broken, three people are messaging you, and you start changing things until it works again. Sometimes it does. Often you never learn why, and occasionally you make the outage bigger. A structured network troubleshooting methodology replaces that guesswork with a repeatable process. It is not slower. In practice it is much faster, because you stop testing the same things twice and you stop chasing symptoms. This guide gives you a step-by-step process, the four classic troubleshooting approaches and when to use each, and a command toolkit for Windows, Linux and Cisco IOS. ## Why a structured approach matters Unstructured troubleshooting has three costs. It is slow, because you skip around and repeat tests. It is risky, because changes made under pressure without a hypothesis can introduce new faults. And it does not compound, because nothing you learn is captured for next time. A structured approach gives you: - Speed through elimination. Each test removes a chunk of the possible causes, so the search space shrinks quickly. - Defensible decisions. You can explain to a manager or vendor exactly what you tested and what you ruled out. - Safer changes. You change one thing at a time, for a reason, with a rollback plan. - Team scalability. A junior admin following the process produces useful evidence even if a senior engineer finishes the job. Experienced engineers often look like they jump straight to the answer. What they are actually doing is running this process very quickly, using pattern recognition to choose which test to run first. The method is still there underneath. ## The troubleshooting process, step by step Most frameworks, including the one taught for CompTIA Network+ and Cisco's structured troubleshooting model, follow the same core steps. Here is a practical version: - Define the problem precisely. "The internet is down" is not a problem statement. "Users on the third floor cannot load any HTTPS sites since 09:40, while the second floor works" is. Ask who is affected, what exactly fails, since when, and what still works. - Gather information. Check monitoring dashboards, logs, recent changes and tickets. Reproduce the issue yourself if possible. Ask the most valuable question in operations: what changed? - Establish a theory of probable cause. Based on the evidence, list likely causes and rank them by probability and ease of testing. - Test the theory. Run a test that will clearly confirm or rule out the cause. If it is ruled out, go back to step 3 with the new information. - Plan and implement the fix. Consider impact, maintenance windows and rollback. For anything non-trivial, follow your change process even during an incident. - Verify full functionality. Confirm with the affected users, not just from your own laptop. Check that you did not break anything else. - Document and prevent. Capture the root cause, the fix and what monitoring or design change would prevent a repeat. Pro tip: Write down the problem statement and every test you run, with timestamps, in the ticket as you go. It feels slow for the first two minutes and saves enormous time later, especially when you hand over to a colleague or open a vendor case. ### Questions that define the scope The scope of a problem is one of the strongest clues you have. Before touching any device, try to answer: - Is it one user, one VLAN, one site, or everyone? - Is it one application, one destination, or everything? - Is it wired, wireless, VPN, or all of them? - Is it constant, intermittent, or tied to a time of day? - Did anything change: a configuration, a firmware upgrade, a certificate expiry, a new device, a desk move? One user failing while neighbors work points at the endpoint, its cable or its switch port. A whole VLAN failing points at the gateway, DHCP or a trunk. Everything failing to one cloud application points at DNS, the firewall, the internet edge or the provider. Scoping well often shrinks the search space dramatically before you run a single command. ## Using the OSI model: bottom-up and top-down The OSI model is a troubleshooting tool, not just an exam topic. It gives you a checklist of what must be working for communication to succeed, layer by layer. Layer | What to verify | Typical faults | 1 Physical | Link lights, cable, optics, interface status, error counters | Bad patch cable, dirty fiber, wrong SFP, duplex mismatch, CRC errors | 2 Data link | VLAN assignment, trunk allowed list, MAC table, spanning tree | Wrong access VLAN, VLAN pruned from trunk, STP blocking, err-disabled port | 3 Network | IP address, mask, gateway, routes, ACLs | Wrong mask, missing route, duplicate IP, asymmetric routing | 4 Transport | TCP or UDP port reachability, firewall policy, NAT | Port blocked, NAT rule missing, session table exhausted | 5 to 7 Upper layers | DNS, TLS certificates, authentication, application service | Wrong DNS record, expired certificate, service stopped, proxy misconfiguration | ### Bottom-up Start at layer 1 and work upward, proving each layer before moving on. It is thorough and ideal when you suspect a physical or local problem: a single user after a desk move, a newly installed switch, an interface showing errors. Its weakness is speed. Checking cables for an issue that turns out to be an expired certificate wastes time. ### Top-down Start at the application and work downward. Use it when the symptom is clearly application-specific: one website fails while others work, or email works but file shares do not. If the browser shows a certificate error, you have already learned that layers 1 through 4 work, because the TLS handshake started. Top-down is fast when lower layers are obviously healthy and slow when they are not. ## Divide-and-conquer Divide-and-conquer starts in the middle, usually at layer 3, and uses the result to decide which direction to go. A successful ping to the destination proves layers 1 through 3 along the whole path, so you move up. A failed ping means you move down or along the path. This is the default approach for most experienced engineers because one or two tests can eliminate half the stack. A typical opening sequence looks like this: - Check the host's IP configuration: address, mask, gateway and DNS servers. - Ping the default gateway. Failure points at the local segment: cable, VLAN, port, IP settings. - Ping a known external IP address. Failure with a working gateway points at routing, the firewall or the internet edge. - Resolve a name. Success by IP but failure by name points straight at DNS. - Test the actual application port. Success on ICMP but failure on TCP 443 points at a firewall, proxy or service problem. Watch out: A failed ping is not proof of a fault. Many hosts and firewalls block ICMP by design, including Windows hosts with the default firewall profile. Always confirm with a test of the real service, such as a TCP connection to the application port. ## Follow-the-path and compare-to-known-good ### Follow the path This approach traces the actual route traffic takes from source to destination and checks each device along the way: access switch, distribution, core, firewall, WAN, and the far side. You use traceroute, routing tables, MAC and ARP tables and interface counters to confirm where traffic goes and where it stops. It is especially powerful for problems such as asymmetric routing, where traffic leaves through one firewall and returns through another that drops it as an unknown session. Following the path is only as good as your knowledge of the path. Accurate diagrams and IP documentation make it dramatically faster, which is one of the strongest arguments for the practices in the network documentation guide. ### Compare to known good When one site, switch or user works and another does not, compare them. Diff the configurations, firmware versions, VLAN assignments or client settings. This is often the fastest approach when you have a working reference, and it pairs well with configuration backups that let you diff today's configuration against last week's. ### Swap components Swapping a cable, a patch port, an SFP or a laptop is a legitimate test when it is quick and safe. Note what you swapped, because a fix by swapping still needs a root cause: a bad cable is a cable, but a port that keeps killing cables is something else. ## The command toolkit: Windows, Linux and Cisco IOS You do not need hundreds of commands. You need a dependable core set and the habit of reading their output carefully. This table maps the most useful tasks across the three platforms you are most likely to work on. Task | Windows | Linux | Cisco IOS | Show IP configuration | ipconfig /all | ip addr show | show ip interface brief | Test reachability | ping 10.1.1.1 | ping -c 4 10.1.1.1 | ping 10.1.1.1 | Trace the path | tracert 10.1.1.1 | traceroute 10.1.1.1 or mtr 10.1.1.1 | traceroute 10.1.1.1 | Test DNS resolution | nslookup host or Resolve-DnsName host | dig host or host host | ping host (with ip domain lookup enabled) | Test a TCP port | Test-NetConnection host -Port 443 | nc -zv host 443 | telnet host 443 | View the routing table | route print | ip route show | show ip route | View ARP / neighbors | arp -a | ip neigh show | show ip arp | Listening ports and sessions | netstat -ano | ss -tulpn | show tcp brief | Interface errors and stats | Get-NetAdapterStatistics | ip -s link or ethtool -S eth0 | show interfaces | Test path MTU | ping -f -l 1472 host | ping -M do -s 1472 host | ping host size 1500 df-bit | Flush DNS cache | ipconfig /flushdns | resolvectl flush-caches | clear host * | Capture packets | pktmon or Wireshark | tcpdump | monitor capture (IOS XE) | Discover neighbors | Not built in | lldpctl (lldpd package) | show cdp neighbors or show lldp neighbors | The 1472-byte payload in the MTU test is not arbitrary: 1472 bytes of ICMP data plus an 8-byte ICMP header and a 20-byte IPv4 header equals 1500 bytes, the standard Ethernet MTU. If that test fails with "fragmentation needed" or no reply while smaller sizes work, you have found an MTU problem, common on VPNs and PPPoE links. ### Layer 1 and 2 checks on a Cisco switch ``` show interfaces GigabitEthernet1/0/12 show interfaces status err-disabled show interfaces GigabitEthernet1/0/12 transceiver show vlan brief show interfaces trunk show mac address-table interface GigabitEthernet1/0/12 show spanning-tree vlan 20 ``` In show interfaces, look at input errors, CRC errors and late collisions. Rising CRC errors almost always mean a physical problem: a damaged cable, a bad patch panel termination or a dirty fiber connector. Late collisions on a full-duplex link usually indicate a duplex mismatch. The structured cabling and fiber basics guide explains how to test and fix the physical side. For VLAN and trunk faults, the VLANs explained guide covers allowed lists, native VLAN mismatches and inter-VLAN routing. ### Upper-layer checks from a Linux host ``` ip route get 10.20.30.40 dig +short app.example.com dig @10.0.0.53 app.example.com nc -zv app.example.com 443 curl -sv https://app.example.com/ -o /dev/null sudo tcpdump -ni eth0 host 10.20.30.40 and port 443 ``` Querying a specific DNS server with dig @server quickly reveals whether internal and external resolvers disagree. The verbose curl output shows the DNS result, the TCP connection, the TLS handshake and the HTTP response in order, which makes it a top-down troubleshooting tool in a single command. ## A worked example Here is how the methodology plays out on a realistic ticket: "Accounting cannot open the file server, everything else works." - Define: All users in the accounting VLAN cannot map the file share since this morning. Web browsing and email work. Users in other departments can reach the file server. - Scope: One VLAN, one destination. That rules out the file server itself (others reach it) and the accounting users' general connectivity (internet works). - What changed: The change log shows a firewall rule cleanup last night. - Theory: Traffic from the accounting subnet to the file server on TCP 445 is now blocked. - Test: From an accounting PC, Test-NetConnection fileserver -Port 445 fails while ping succeeds. The firewall log shows denies from the accounting subnet to the server on TCP 445, matching a rule removed in the cleanup. - Fix and verify: Restore a scoped rule through the change process, confirm with users, and confirm the log now shows allows. - Document and prevent: Record the root cause and add a pre-change review of rule hit counts before cleanups. Notice what did not happen: nobody rebooted the file server, nobody replaced cables and nobody spent an hour on DNS. Scoping and "what changed?" got to a strong hypothesis in minutes. Rule cleanups like this are worth doing, and the firewall hardening checklist explains how to do them safely. ## Habits that make troubleshooting faster The best troubleshooting happens before the incident. These habits shorten every future outage: - Know your baseline. Normal interface utilization, error rates, CPU and latency make abnormal values obvious. Monitoring with SNMP, syslog and flow data, as described in Network Monitoring 101, provides that baseline. - Centralize logs with accurate time. Correlating events across devices is impossible if clocks disagree. Use NTP everywhere. - Back up configurations automatically so you can diff before and after a change. Scripting this with Python or Ansible is a great first automation project. - Keep diagrams current. Follow-the-path only works when you know the path. - Change one thing at a time and record it. Multiple simultaneous changes make cause and effect impossible to separate. - Communicate on a schedule. A short update every 30 minutes stops the flood of "any news?" messages and lets you focus. - Run blameless post-incident reviews. Focus on what the system and process allowed, not on who typed the command. Note: Escalating is part of the method, not a failure of it. When the fault is in a carrier circuit, a cloud service or a vendor bug, escalate early with clear evidence: the problem statement, the tests you ran, timestamps and outputs. Good evidence gets you past first-line support faster. ## Key takeaways - Follow a consistent process: define, gather, hypothesize, test, fix, verify, document. - Scope the problem first: who, what, where, since when, and what changed. - Use bottom-up for physical or local symptoms, top-down for application-specific issues, and divide-and-conquer when you have no strong clue. - Follow the path and compare to known good when you have diagrams and working references. - Master a small cross-platform command toolkit and test the real service, not just ping. - Invest in baselines, logging, backups and documentation so the next incident is shorter. If recurring issues keep eating your week, the root cause is often in the design, monitoring or documentation rather than in any single device. A Network Health Assessment finds those weak spots and gives you a prioritized plan, and the free network tools help with subnet math and port lookups on your next ticket. Need hands-on help with a stubborn problem? Contact us. ## FAQ Q: Which troubleshooting approach should I use first? A: If you have no strong clue, start with divide-and-conquer at the network layer: a ping to the default gateway and to the destination splits the problem in half immediately. If the symptom points at a physical issue, such as one user after a desk move, go bottom-up. If only one application is affected and others work, go top-down. Q: Why does ping work but the application still fails? A: Ping only proves ICMP reachability at layer 3. The application may be blocked by a firewall or ACL on its TCP or UDP port, fail at DNS resolution, hit an MTU problem with larger packets, or fail at the TLS or authentication stage. Test the actual port with Test-NetConnection, nc or telnet, and test name resolution separately. Q: Is traceroute output with asterisks a problem? A: Not necessarily. Many routers and firewalls rate-limit or block the ICMP messages traceroute relies on, so a hop showing asterisks while later hops respond is usually harmless. It is only meaningful when every hop after a certain point times out and the destination is unreachable. Q: How do I know when to escalate a network problem? A: Escalate when the fault is outside your control (a carrier circuit, a cloud provider or a vendor bug), when the impact exceeds what you are authorized to change, or when an agreed time limit has passed without progress. Escalate with evidence: what you tested, what you ruled out and the exact commands and outputs. Q: What should I document after fixing an issue? A: Record the symptom, the root cause, the fix, the time to resolution and what would have detected it sooner. Update diagrams, runbooks and monitoring if the incident exposed gaps. Good incident notes turn one painful outage into a fast fix the next time. --- # Firewall Hardening Checklist for Small Business Networks URL: https://roadtoneteng.com/firewall-hardening-checklist/ Updated: 2026-10-14 In many small businesses, the firewall was configured once during installation, then left alone while the business grew around it. New rules were added in a hurry, nobody removed the old ones, the firmware is a few versions behind and the admin page is still reachable from places it should not be. None of this is unusual, and all of it is fixable. This vendor-neutral firewall hardening checklist walks you through the controls that matter most: preparation, the management plane, rule-base hygiene, inbound and outbound policy, VPN, segmentation, zero trust principles, logging and lifecycle. It applies whether you run a small appliance or a pair of enterprise next-generation firewalls. ## Before you start: inventory, backup and baseline Hardening a firewall you do not fully understand is how outages happen. Spend the first hour on preparation: - Back up the current configuration and store it off the device. Confirm you know how to restore it. - Record the hardware model, firmware version and licenses, including when support and security subscriptions expire. - Inventory interfaces and zones: which networks sit behind which interface, and which are trusted, untrusted or somewhere in between. - Export the rule base with hit counts so you can see which rules are actually used. - List every published service: port forwards, VPN portals, and anything the internet can reach. - Agree on a maintenance window and a rollback plan with the business. Write the results down. A current diagram and a rule inventory make every later step faster and are the foundation of the practices in the network documentation guide. Watch out: Never remove rules on the assumption that they are unused based only on a short observation period. Some rules support monthly or quarterly processes such as payroll exports or backups to an offsite provider. Disable first, monitor, then delete. ## Harden the management plane The management plane is how administrators reach and configure the firewall. If an attacker controls it, every other control is irrelevant. Firewall and VPN management interfaces have been the target of many serious vulnerabilities, so treat this section as top priority. - Disable management access from the internet on the WAN interface. If remote administration is required, reach the firewall through a VPN first. - Restrict management to a dedicated management network or a short list of administrator IP addresses. - Use encrypted protocols only: HTTPS (TCP 443) and SSH (TCP 22). Disable HTTP, Telnet (TCP 23) and any legacy management protocols. - Change or disable default accounts, and rename the default administrator account where the platform allows it. - Use individual named accounts for every administrator, never a shared login, so actions are traceable. - Enable multi-factor authentication for administrative access, ideally through central authentication with RADIUS or TACACS+ tied to your directory. - Apply role-based access control: read-only accounts for monitoring and help desk staff, full rights only for those who need them. - Keep one local break-glass account with a long random password stored in a password vault, for when central authentication is unavailable. - Set idle session timeouts and login lockout after repeated failures. - Replace the self-signed management certificate with one from your internal or public CA so administrators are not trained to click through warnings. - Use SNMPv3 with authentication and encryption, or disable SNMP. Remove default SNMPv1 and v2c communities such as "public." - Configure NTP from reliable sources so logs and certificates work correctly. - Disable unused services on the firewall itself, such as UPnP, unused DHCP or DNS services, and unused remote access portals. ## Rule-base hygiene A firewall is only as good as its rule base. Over the years, rule bases collect "temporary" rules that became permanent, overly broad rules created to make something work quickly, and duplicates nobody dares to remove. Cleaning this up has a real security payoff and makes troubleshooting much easier. ### Principles - Default deny. Anything not explicitly allowed is blocked. End each policy with an explicit deny rule that logs, so you can see what is being blocked. - Least privilege. Each rule allows only the specific source, destination and service required. Avoid "any" in more than one field of a rule, and never use any-to-any-allow. - Specific rules above general rules. Firewalls evaluate rules top-down and stop at the first match, so order matters. - Every rule has an owner and a reason. Use the description or comment field for the business purpose, the requester, a ticket number and the date. - Temporary rules expire. Use scheduled rules or calendar reminders, and review them on the date. ### Cleanup tasks Finding | What it means | Action | Zero hit count over a long period | The rule may be unused | Confirm with the owner, disable, monitor, then remove | Shadowed rule | A rule above it already matches all its traffic, so it never matches | Remove it or reorder if the intent was different | Redundant rule | Duplicates the effect of another rule | Consolidate into one | Overly broad rule | "Any" source, destination or service where a narrower scope works | Use logs to see what actually matches and narrow it | No description or owner | Nobody knows why it exists | Investigate, document or retire | Rules referencing old hosts | Objects point at decommissioned servers or IPs | Remove rules and objects; reused IPs can grant unintended access | Use named objects and groups rather than raw IP addresses. A rule that allows "ACCOUNTING-USERS" to "FILE-SERVERS" on "SMB" is easier to review than a list of addresses and port numbers, and changes become safer. ## Inbound exposure, remote access and egress filtering ### Reduce inbound exposure Every service reachable from the internet is attack surface. Go through each published service and ask whether it truly needs to be public. - Never expose Remote Desktop (TCP 3389), SMB (TCP 445) or database ports directly to the internet. Put remote access behind a VPN with MFA or a zero trust access service. - Publish only what is required, to the specific internal host and port, and prefer hosting public services in a DMZ or with a hosting provider rather than on the internal network. - Restrict source addresses where possible. If only a partner's network needs access, allow only that range. - Use geo-blocking with care. It reduces noise but is easily bypassed, so treat it as an extra layer, not a control you rely on. - Remember IPv6. If your firewall and ISP provide IPv6, apply equivalent inbound policy. A strict IPv4 policy with a permissive IPv6 policy is a common gap. The IPv6 for network admins guide covers what to allow, including the ICMPv6 types IPv6 needs to work. Verify from the outside. A scan of your public address from an external host shows what the internet sees, which is often different from what you think you configured: ``` # Run only against addresses you own and are authorized to test nmap -Pn -sS -p- --open 203.0.113.10 nmap -Pn -sU --top-ports 50 203.0.113.10 ``` ### Harden VPN and remote access Remote access gateways are among the most attacked devices on any network. Harden them deliberately: - Require MFA for every remote user, without exceptions for executives or service accounts. - Use modern cryptography. For IPsec, prefer IKEv2 with AES-GCM, SHA-256 or stronger, and Diffie-Hellman groups 19, 20 or 21 (or at least group 14). Disable IKEv1 aggressive mode, DES, 3DES, MD5 and DH groups 1, 2 and 5. - Limit what VPN users reach. Apply firewall policy to VPN traffic by user or group instead of giving every remote user access to the entire internal network. - Patch quickly. VPN appliance vulnerabilities are often exploited within days of disclosure. Track the CISA Known Exploited Vulnerabilities catalog and your vendor's advisories. - Disable unused portals, such as a legacy web VPN you replaced years ago. - Review accounts: remove VPN access for leavers on the same day, and audit regularly. ### Filter outbound traffic Many small business firewalls allow all outbound traffic. That makes life easy for malware, which needs to reach command-and-control servers and move data out. You do not need a perfect allow list on day one; start with high-value restrictions: - DNS: allow UDP and TCP 53 outbound only from your internal resolvers or DNS filtering service. Consider blocking DNS over TLS (TCP 853) from clients, and use your platform's options for managing DNS over HTTPS if you rely on DNS filtering. - SMTP: allow TCP 25 outbound only from your mail server or relay, if you have one. Workstations should never send mail directly. - SMB and NetBIOS: block TCP 445 and TCP/UDP 137 to 139 to the internet. - NTP: allow UDP 123 to your chosen time sources. - Servers: restrict servers to only the outbound destinations they need, such as update services. Servers browsing the internet freely is a red flag. ## Segmentation and zero trust principles A flat network, where every device can talk to every other device, lets one compromised laptop reach your servers, printers, cameras and backups. Segmentation limits that blast radius. In a small business, segmentation usually means VLANs, each mapped to a firewall zone or interface, with policy between them. The VLANs explained guide covers the switching side. Segment | Contains | Typical policy | Users | Staff laptops and desktops | Internet access; specific server ports only | Servers | File, application and directory servers | Reachable from users on required ports only; limited outbound | Management | Switch, firewall, AP and hypervisor management interfaces | Reachable only from admin workstations or a jump host | Voice | IP phones | Call control and media to the PBX or cloud provider | IoT and building systems | Cameras, printers, sensors, door controllers | No access to users or servers; only required cloud or controller destinations | Guest | Visitor devices | Internet only; no internal access at all | Backup | Backup servers and storage | Tightly restricted; ideally pulled from, not pushed to | ### Applying zero trust principles Zero trust, as described in NIST SP 800-207, is not a product you buy. It is a set of principles you can apply incrementally, even in a small network: - Never trust based on location. Being on the internal network or VPN should not grant broad access by itself. - Verify explicitly. Base access on user identity, device health and context, using identity-aware firewall rules or access proxies where available. - Use least privilege. Grant access to specific applications, not entire subnets. - Assume breach. Design segmentation and logging so a compromised device is contained and detected quickly. Pro tip: Segment in phases. Start with guest and IoT, which are easy to isolate and carry the most risk, then separate management, then servers. Use logging rules between segments for a week before switching to deny, so you discover real dependencies before you break them. ## Security services and inspection Next-generation firewalls offer intrusion prevention, application control, URL and DNS filtering, malware scanning and TLS inspection. They add real value when they are licensed, updated and tuned: - Keep subscriptions active. An IPS with expired signatures provides little protection while giving a false sense of security. - Apply IPS to the traffic that matters most: inbound published services, traffic between users and servers, and outbound user traffic. - Use DNS or URL filtering to block known malicious and newly registered domains. It is one of the most cost-effective controls available. - Plan TLS inspection carefully. It increases visibility but requires certificate deployment, exceptions for sensitive categories such as banking and healthcare, and consideration of privacy obligations and performance. ## Logging, monitoring and alerting Logs you never read do not protect you, but logs you do not keep make incidents impossible to investigate. Aim for both: - Log denied traffic, allowed traffic on sensitive rules, VPN authentication, admin logins and every configuration change. - Send logs off the device to a syslog server or SIEM. Traditional syslog uses UDP 514; prefer TCP or syslog over TLS (TCP 6514) for reliability and confidentiality where supported. - Synchronize time with NTP so events correlate across devices. - Define retention that meets your investigative and regulatory needs. - Alert on high-value events: configuration changes, admin logins from unusual sources, repeated VPN failures, IPS critical events and high-availability failovers. - Monitor health: CPU, memory, session counts, interface errors and license expiry. The Network Monitoring 101 guide explains how to build syslog, SNMP and alerting into a practical monitoring stack, and logs are the first place you will look when you apply the structured troubleshooting methodology to a blocked application. ## Firmware, lifecycle and change management - Patch on a schedule and out of band for critical, actively exploited vulnerabilities. - Track end-of-life dates. A firewall that no longer receives security updates should be replaced, not tolerated. - Use high availability where downtime is costly, and test failover periodically. - Back up configurations automatically after every change, and store copies securely off the device. - Use change control: describe the change, the reason, the rollback and the verification, even if the approver is only one other person. - Audit annually against this checklist or a framework such as the CIS Benchmarks or NIST SP 800-41. ## The checklist at a glance Use this summary to plan the work. Priorities assume a typical small business; adjust them to your own risk and compliance requirements. Tackle the high-priority items first, since they close the paths attackers use most often, then schedule the rest as a project rather than squeezing it into a single evening. Area | Control | Priority | Preparation | Configuration backup, firmware and license inventory, rule export with hit counts | High | Management plane | No management from the internet; HTTPS and SSH only; restricted admin sources | High | Management plane | Named accounts, MFA, role-based access, break-glass account in a vault | High | Inbound | No published RDP, SMB or database ports; external scan matches intent | High | Remote access | MFA for every VPN user, modern IKEv2 cryptography, prompt patching | High | Rule base | Default deny with logging; no any-to-any rules; owner and reason on every rule | High | Egress | DNS only via approved resolvers; SMTP only from the mail relay; outbound SMB blocked | Medium | Segmentation | Guest and IoT isolated, then management, then servers | Medium | Logging | Off-box syslog, NTP, alerts on config changes and admin logins | Medium | Security services | Active subscriptions, IPS on key flows, DNS filtering | Medium | Rule base | Quarterly review of unused, shadowed and expired rules | Ongoing | Lifecycle | Patch schedule, end-of-life tracking, tested HA failover, annual audit | Ongoing | ## Key takeaways - Prepare first: back up, inventory and export rule hit counts before you change anything. - Lock down the management plane: no internet management, MFA, named accounts, encrypted protocols only. - Keep a clean, documented, least-privilege rule base with default deny and logged denies. - Minimize inbound exposure, never publish RDP or SMB, and add egress filtering for DNS, SMTP and SMB. - Segment users, servers, management, IoT and guests, and apply zero trust principles incrementally. - Centralize logs with accurate time, alert on what matters, and keep firmware and subscriptions current. Hardening a production firewall without breaking the business takes care and experience. The Firewall & Security Hardening service reviews your configuration against this checklist and implements the fixes safely, and the Small Business Network Setup service builds a segmented, secure network from the ground up. Have questions about your environment? Contact us. ## FAQ Q: How often should firewall rules be reviewed? A: Review the full rule base at least quarterly and after any major change, such as a new application, office or provider. Use hit counts to find unused rules, check that every rule still has an owner and a business reason, and remove temporary rules whose expiry date has passed. Q: Is it safe to expose RDP or the firewall admin page to the internet if I use a strong password? A: No. Internet-exposed remote desktop and management interfaces are scanned constantly and are a common entry point for ransomware. Put them behind a VPN with multi-factor authentication or a zero trust access service, and restrict management to a dedicated internal network. Q: Do I need outbound (egress) filtering on a small business firewall? A: Yes. Allowing all outbound traffic makes it easy for malware to reach command-and-control servers and exfiltrate data. Start by restricting high-risk protocols such as outbound SMB, direct SMTP from workstations and DNS to anything other than your approved resolvers, then tighten further over time. Q: What logs should a small business firewall keep? A: At minimum, log denied traffic, allowed traffic on sensitive rules, VPN logins, administrator logins and configuration changes. Send logs to an external syslog server or SIEM with accurate NTP time so they survive a firewall failure or compromise, and keep them long enough to investigate incidents. Q: Does zero trust mean I can remove my firewall? A: No. Zero trust is a set of principles, not a product, and it changes how you grant access rather than removing network controls. Firewalls remain essential for segmentation and enforcement, but rules become narrower, identity-aware where possible, and based on the assumption that any network may be compromised. --- # Enterprise Wi-Fi Design: Site Surveys, Channels and Seamless Roaming URL: https://roadtoneteng.com/enterprise-wifi-design/ Updated: 2026-10-14 Users judge the entire network by the Wi-Fi. If video calls stutter in the meeting room or a laptop drops when someone walks to the kitchen, nobody cares how well the core switches are configured. Good enterprise Wi-Fi design is the difference between a wireless network that just works and one that generates a steady stream of tickets. This guide covers the decisions that matter: how to gather requirements, how to survey a site, how to plan channels across 2.4, 5 and 6 GHz, how wide those channels should be, how to make roaming seamless with 802.11k, v and r, how to secure the network with WPA3, and how to plan for capacity rather than just coverage. ## Start with requirements, not access points The most common Wi-Fi design mistake is starting with a number of access points. Start with what the network must support instead: - Devices: how many users, how many devices per user, and what kinds (laptops, phones, scanners, IoT sensors, voice handsets). Note the oldest and least capable clients, because they constrain the design. - Applications: video conferencing, voice over Wi-Fi, file transfers, cloud apps, real-time inventory scanning. Each has different throughput, latency and roaming requirements. - Areas: open offices, meeting rooms, auditoriums, warehouses, outdoor spaces. Each area gets its own coverage and capacity targets. - Security: corporate, guest and IoT access, and how each authenticates. - Constraints: building materials, ceiling types, mounting options, cabling paths, aesthetics, budget and regulatory domain. From these requirements you derive design targets. Common targets for a voice-grade enterprise network are a primary signal strength of about -67 dBm, a signal-to-noise ratio of at least 25 dB, and a second access point audible at roughly the same level in every location so clients have somewhere to roam. Data-only areas can tolerate weaker signals, while dense areas need more attention to capacity than to coverage. Note: Signal strength targets refer to what the client hears, measured with a calibrated survey adapter. Different devices report signal differently, so a phone's bars are not a design measurement. ## Site surveys: predictive, passive and active A site survey translates requirements into a design that fits the actual building. There are several types, and a professional design usually combines them. Survey type | How it works | Best used for | Predictive | Floor plans are imported into planning software, walls are assigned attenuation values, and AP placement is modeled | Initial design, budgeting and new buildings | AP-on-a-stick (APoS) | A real AP is temporarily mounted at planned locations and measured | Validating predictions in difficult buildings, warehouses and healthcare | Passive | A survey adapter listens to all beacons while you walk the site | Measuring coverage and co-channel interference of an existing network | Active | The survey device connects to the network and measures throughput, retries and roaming | Validating real client experience and roaming behavior | Spectrum analysis | A spectrum analyzer detects non-Wi-Fi interference | Finding microwave ovens, wireless cameras, Bluetooth and other interferers | For a new deployment, the typical sequence is a predictive design, an APoS validation in representative areas, installation, and then a post-deployment passive and active validation survey. For an existing network with complaints, start with a passive survey and spectrum analysis to find out what is really happening. ### Building materials matter Drywall attenuates relatively little, while concrete, brick, elevator shafts, metal shelving, coated glass and water (including people) absorb or reflect much more. Higher frequencies lose more signal through obstacles, which is why 5 and 6 GHz cells are smaller than 2.4 GHz cells. Accurate wall types in the predictive model are the single biggest factor in prediction quality. ### Quick client-side checks Survey tools are essential for design, but built-in commands are useful for a quick look at what a client sees: ``` # Windows: current connection, then every visible BSSID with channel and signal netsh wlan show interfaces netsh wlan show networks mode=bssid # Linux: scan and show SSID, frequency and signal for each BSS sudo iw dev wlan0 scan | grep -E "BSS|SSID|freq|signal" ``` ## Bands and channel planning: 2.4, 5 and 6 GHz Each band has distinct characteristics. A modern enterprise design uses all three deliberately rather than treating them as interchangeable. Band | Non-overlapping 20 MHz channels (US) | Strengths | Limitations | 2.4 GHz | 3 (channels 1, 6 and 11) | Longer range, supported by nearly every device | Very few channels, crowded, interference from Bluetooth and microwaves | 5 GHz | Up to 25, depending on DFS channel use | Many channels, good balance of range and capacity | DFS channels can be vacated when radar is detected; some clients avoid DFS | 6 GHz | 59 (5.925 to 7.125 GHz) | Clean spectrum, wide channels, only modern clients | Shorter range, requires Wi-Fi 6E or Wi-Fi 7 clients and WPA3; availability varies by country | ### 2.4 GHz In the US, use only channels 1, 6 and 11 at 20 MHz. Using other channels creates adjacent-channel interference that is worse than sharing a channel. Because 2.4 GHz cells are larger, an AP density chosen for 5 GHz usually results in too many 2.4 GHz radios. Disable 2.4 GHz on some APs or convert those radios to 5 GHz or monitoring, so the 2.4 GHz cells do not overlap excessively. Keep 2.4 GHz for legacy and IoT devices that need it. ### 5 GHz The 5 GHz band is the workhorse of most current networks. Channels in the UNII-2 and UNII-2 Extended ranges require Dynamic Frequency Selection (DFS): if an AP detects radar, it must leave the channel. Include DFS channels to gain capacity, but check that your critical clients support them, and watch for frequent radar events near airports, ports and weather stations. ### 6 GHz The 6 GHz band, opened for Wi-Fi 6E and used by Wi-Fi 7, is the biggest improvement in spectrum in decades. In the US, 1,200 MHz is available: 59 channels at 20 MHz, 29 at 40 MHz, 14 at 80 MHz and 7 at 160 MHz, plus 320 MHz channels for Wi-Fi 7. Other regions, including much of Europe, allow a smaller portion of the band, so check your regulatory domain. Indoor enterprise APs typically operate in Low Power Indoor (LPI) mode, while Standard Power operation requires coordination through an Automated Frequency Coordination (AFC) system. Because 6 GHz is reserved for newer devices, it is free from legacy clients and their slow transmissions, which makes it ideal for high-performance SSIDs. Since 6 GHz signals attenuate more, a common approach for new deployments is to plan AP density for 6 GHz coverage, which comfortably covers 5 GHz as well. ## Channel width, transmit power and data rates ### Channel width Wider channels deliver higher peak speeds for a single client, but they reduce the number of channels available for reuse. In a multi-AP building, that means more APs sharing the same channel, which creates co-channel contention: radios on the same channel must take turns, so total capacity can drop. - 2.4 GHz: always 20 MHz. - 5 GHz: 20 MHz in very dense environments, 40 MHz in most offices. Use 80 MHz only in low-density areas or where you have few APs. - 6 GHz: 80 MHz is often practical thanks to the large number of channels; 160 MHz and 320 MHz suit specific high-throughput areas with few nearby APs. ### Transmit power Running APs at maximum power is a classic mistake. A loud AP may be heard by a client far away, but the client, which typically transmits at lower power, cannot be heard as well in return. The result is asymmetric links, sticky clients and more co-channel interference. Set AP power to create appropriately sized cells, and keep it in a range closer to what typical clients transmit. Let the controller's radio resource management adjust within minimum and maximum limits that you define. ### Minimum data rates Disable the legacy 802.11b rates (1, 2, 5.5 and 11 Mbps) and set a higher minimum basic rate, commonly 12 or 24 Mbps on 5 GHz. Management frames such as beacons are sent at the lowest basic rate, so higher minimum rates reduce airtime overhead, shrink the effective cell edge and encourage clients to roam sooner. Test before raising rates aggressively, because some older devices may lose connectivity at the edge. Pro tip: Limit the number of SSIDs. Every SSID beacons separately on every radio, and the overhead adds up quickly. Three or four SSIDs, such as corporate, guest and IoT, is a practical maximum. Use dynamic VLAN assignment from RADIUS instead of creating a new SSID for every user group. ## Seamless roaming with 802.11k, 802.11v and 802.11r In Wi-Fi, the client decides when and where to roam. Access points can only help it make a good decision and complete the move quickly. Three amendments do most of that work. Amendment | Name | What it does | 802.11k | Radio Resource Measurement | The AP provides a neighbor report listing nearby APs and channels, so the client scans fewer channels before roaming | 802.11v | BSS Transition Management | The network can suggest that a client move to a better AP, for example when the client's signal is weak or the AP is overloaded | 802.11r | Fast BSS Transition (FT) | Key derivation for the new AP happens in advance, so the client avoids a full 802.1X or SAE authentication when it roams | The value of 802.11r is largest on 802.1X networks, where a full EAP authentication against a RADIUS server can take long enough to interrupt voice and video. With fast transition, the key exchange is folded into the reassociation, keeping the roam short enough that real-time applications are not disrupted. Roaming also depends on the network design underneath. Clients roam well when: - Every location has a strong secondary AP, so there is somewhere to go. - Cells are sized with appropriate power and minimum rates, so clients do not cling to distant APs. - The same SSID, security settings and VLAN are available across the roaming area, so the client keeps its IP address. - Client drivers are current. Driver updates often fix roaming behavior more than any AP setting can. Watch out: Some older clients fail to connect to SSIDs that advertise 802.11r. Before enabling it everywhere, test with your real device fleet, especially barcode scanners, printers, medical devices and other specialty equipment. Many platforms support an adaptive or mixed mode that serves both kinds of clients. ## Security: WPA3, 802.1X and segmentation Wireless security choices today are clearer than they used to be: - WPA3-Enterprise with 802.1X is the standard for corporate devices. Use EAP-TLS with certificates where possible, so there are no passwords to phish. Authentication happens against a RADIUS server using UDP 1812, with accounting on UDP 1813. WPA3-Enterprise also offers an optional 192-bit mode for high-security environments. - WPA3-Personal uses Simultaneous Authentication of Equals (SAE), which resists offline dictionary attacks against the passphrase. Use it for small sites and IoT where 802.1X is impractical, ideally with per-device or per-group passphrases if your platform supports them. - Protected Management Frames (802.11w) are mandatory with WPA3 and prevent spoofed deauthentication attacks. - Enhanced Open (OWE) encrypts guest traffic without a password, which is a big improvement over open guest networks. - WPA3 transition mode allows WPA2 and WPA3 clients on one SSID during migration, but it keeps some WPA2 weaknesses. Plan to retire it. Map each SSID to a VLAN and enforce policy between those VLANs on the firewall: guests reach the internet only, IoT devices reach only what they need, and corporate devices reach internal resources based on role. The VLANs explained guide covers the switching side, and the firewall hardening checklist covers policy between segments. Remember that hiding an SSID is not a security control, and that many clients now use randomized MAC addresses, which weakens any access control or reporting based on MAC addresses. ## Capacity planning Coverage answers "can I connect?" Capacity answers "does it work when everyone is here?" Most modern problems are capacity problems. Here is a simple, transparent method. - Count devices per area. Multiply users by devices per user and estimate how many are active at once. - Define throughput per device from the applications, for example a few Mbps for HD video calls and less for email and web apps. - Calculate aggregate demand: active devices multiplied by throughput per device. - Divide by realistic throughput per radio, not the theoretical maximum on the box. Real throughput depends on channel width, client capabilities, interference and protocol overhead. - Distribute the radios across bands and channels, then validate with the predictive model. For example, suppose an open office area will have 150 devices active at once, each needing 5 Mbps. Aggregate demand is 150 multiplied by 5, or 750 Mbps. If you assume, for planning purposes, that each 5 GHz radio at 40 MHz delivers about 150 Mbps of usable aggregate throughput in your environment, you need at least 750 divided by 150, or five 5 GHz radios serving that area on separate channels, before adding headroom. With 6 GHz-capable clients in the mix, some of that demand moves to the 6 GHz radios. The assumption is the part to validate; the method stays the same. ### Do not forget the wired side - PoE budget: Wi-Fi 6E and Wi-Fi 7 APs often need IEEE 802.3at (up to 30 W at the switch port) or 802.3bt (60 W for Type 3, 90 W for Type 4) to run all features. Check the switch's total PoE budget, not just the per-port capability. - Uplink speed: modern APs can exceed 1 Gbps. Multigigabit ports (2.5GBASE-T and 5GBASE-T, IEEE 802.3bz) avoid a bottleneck, and Category 6A cabling supports 10GBASE-T at up to 100 meters. The structured cabling and fiber basics guide covers cable categories and testing. - DHCP and addressing: size scopes for peak device counts plus randomized MAC churn, and use shorter lease times on guest networks. ## Validation and ongoing operations A design is not complete until it has been validated. After installation, perform a passive survey to confirm coverage, SNR and channel reuse, and an active survey to confirm throughput and roaming. Walk the routes people actually take, such as corridors, stairwells and between meeting rooms, while running a voice or video call. Then keep the network healthy: - Monitor client counts, channel utilization, retry rates, roaming events and authentication failures. The Network Monitoring 101 guide explains how to bring wireless metrics into your wider monitoring. - Re-survey after significant changes, such as renovations, new furniture layouts or a large increase in headcount. - Keep AP firmware and controller software current, and test client compatibility after major upgrades. - Troubleshoot wireless complaints systematically: identify the client, location, time and AP, then check signal, interference and authentication logs before changing settings, following the structured troubleshooting methodology. ## Key takeaways - Design from requirements: devices, applications, areas and security, then derive signal, SNR and capacity targets. - Combine predictive design with on-site validation; accurate wall attenuation drives prediction quality. - Use channels 1, 6 and 11 on 2.4 GHz, include DFS on 5 GHz where clients allow, and adopt 6 GHz for modern clients. - Prefer 20 or 40 MHz on 5 GHz in dense areas, avoid maximum transmit power, and disable legacy low data rates. - Enable 802.11k and 802.11v, use 802.11r after testing your device fleet, and design for a strong secondary AP everywhere. - Use WPA3-Enterprise with EAP-TLS for corporate devices, OWE for guests, and segment SSIDs into VLANs with firewall policy. - Plan capacity with transparent math, and size PoE, uplinks and DHCP to match. Struggling with dead spots, dropped calls or slow Wi-Fi in busy areas? A Network Health Assessment includes a review of your wireless design and gives you a clear, prioritized plan, and the Small Business Network Setup service designs and deploys Wi-Fi alongside the switching and security it depends on. For anything else, contact us. ## FAQ Q: How many access points do I need? A: There is no reliable square-footage rule. The number depends on capacity (how many devices are active and what they run), coverage requirements for your most demanding application, building materials and ceiling height. Estimate with a predictive model based on device counts and application needs, then validate with an on-site survey. Q: Should I use 80 MHz channels on 5 GHz? A: Usually not in a multi-AP enterprise environment. Wider channels reduce the number of non-overlapping channels, which increases co-channel interference and can lower total capacity. Use 20 or 40 MHz on 5 GHz in most offices and reserve 80 MHz or wider for 6 GHz or for low-density areas. Q: Why do my devices stay connected to a distant access point? A: Roaming decisions are made by the client, not the access point, and some clients hold on to a weak connection too long. Good cell design, disabling low data rates, sensible transmit power and enabling 802.11k and 802.11v help clients make better decisions. Updated client drivers often make a large difference too. Q: Does 6 GHz Wi-Fi require WPA3? A: Yes. Networks in the 6 GHz band must use WPA3 or Enhanced Open (OWE), with Protected Management Frames required. WPA2 and open networks without OWE are not allowed in 6 GHz, so plan your security settings before enabling the band. Q: Is 802.11r safe to enable on all SSIDs? A: Most modern clients support 802.11r, but some older devices fail to connect to an SSID that advertises it. Many platforms offer an adaptive or mixed mode that allows both. Test with your actual device fleet, especially scanners, printers and medical or industrial devices, before enabling it everywhere. --- # Getting Started with Network Automation: Python, Netmiko and Ansible URL: https://roadtoneteng.com/network-automation-python-ansible/ Updated: 2026-10-14 Network automation sounds like something reserved for hyperscalers with dedicated developer teams, but the reality is much more modest and much more useful. If you have ever logged into twenty switches one by one to check a VLAN, copy a running config or add an NTP server, you already have an automation use case. This guide walks you through the exact path that works for most network admins: a working Python script with Netmiko, a first Ansible playbook using the cisco.ios collection, a clean inventory, and a Git workflow that keeps every change reviewable and reversible. ## Why automate, and where to start The best reason to automate is not speed. It is consistency. When a human configures forty access switches by hand, small differences creep in: a missing logging host line here, a typo in a banner there, an NTP server that was decommissioned two years ago but still lives on half the fleet. Those differences are invisible until something breaks, and then they turn a ten-minute fix into an afternoon of investigation. Automation turns your standards into code, and code does the same thing every time. The second reason is that automation forces you to understand your network as data. To write a playbook you need an inventory, which means you need to know what devices you have, what role each plays and how to reach them. That is the same knowledge good documentation needs, which is why automation and the practices in our network documentation guide reinforce each other. ### Pick read-only tasks first Your first automation projects should not change anything. Read-only tasks build confidence and deliver value immediately, with almost zero risk: - Back up running configurations from every device every night. - Collect software versions and serial numbers for an inventory or support-contract review. - Check interface error counters across the whole access layer in one run. - Audit whether every device has the correct NTP, syslog and SNMP settings. - Find which switch port a MAC address lives on by searching every MAC address table. Once those run reliably, move to low-risk changes such as adding an NTP server or updating a login banner, and only then to changes that affect forwarding, such as VLANs or access control lists. Note: You do not need a production network to learn. A handful of virtual IOS or IOS-XE nodes in a lab gives you a safe target for every example in this article. If you have not built one yet, our home network lab guide covers both physical and virtual options. ## Setting up a safe automation workstation Automation code should run from a predictable environment, not from whatever Python happens to be installed on your laptop. A Linux machine, a small virtual machine, or Windows Subsystem for Linux all work well. The key habit is to use a Python virtual environment per project so that library versions do not collide. ``` mkdir net-automation && cd net-automation python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install netmiko ansible-core ansible-pylibssh ansible-galaxy collection install cisco.ios ansible.netcommon pip freeze > requirements.txt ``` Netmiko installs its dependencies automatically, including Paramiko for SSH and the TextFSM templates used to parse show commands into structured data. The ansible-core package gives you the Ansible engine, while the cisco.ios and ansible.netcommon collections provide the modules and the network_cli connection plugin. The ansible-pylibssh package is optional but gives network_cli a faster SSH transport than the Paramiko fallback. ### Prepare the devices Your devices need SSH enabled, a reachable management address, and an account for automation. Avoid a shared "automation" account if you can; per-user accounts authenticated through TACACS+ or RADIUS mean every change is logged against a real person. In a lab, a local user is fine: ``` hostname acc-sw1 ip domain name lab.example.com crypto key generate rsa modulus 2048 ip ssh version 2 username netadmin privilege 15 secret Use-A-Strong-Secret line vty 0 15 login local transport input ssh ``` Watch out: Never store credentials in your scripts or playbooks. Read them from environment variables, prompt for them at run time, or encrypt them with ansible-vault. A password committed to Git stays in the history even after you delete the line. ## Your first Netmiko script Netmiko is a Python library that handles the tedious parts of talking to network devices over SSH: logging in, detecting the prompt, entering enable mode, disabling paging and waiting for output to finish. You give it a dictionary describing the device and it gives you a connection object with methods such as send_command() and send_config_set(). The script below reads a list of devices from a CSV file, connects to each one, collects the software version, saves the running configuration to a timestamped file, and keeps going if one device fails. Create a devices.csv file first: ``` host,role 192.0.2.1,core 192.0.2.11,access 192.0.2.12,access ``` Then save the following as backup.py: ``` #!/usr/bin/env python3 """Back up running configs and report IOS versions for devices in devices.csv.""" import csv import getpass import os from datetime import datetime from pathlib import Path from netmiko import ConnectHandler from netmiko.exceptions import ( NetmikoAuthenticationException, NetmikoTimeoutException, ) USERNAME = os.environ.get("NET_USER") or input("Username: ") PASSWORD = os.environ.get("NET_PASS") or getpass.getpass("Password: ") BACKUP_DIR = Path("backups") BACKUP_DIR.mkdir(exist_ok=True) def load_devices(path): with open(path, newline="") as f: return list(csv.DictReader(f)) def backup_device(host): device = { "device_type": "cisco_ios", "host": host, "username": USERNAME, "password": PASSWORD, "secret": PASSWORD, } with ConnectHandler(**device) as conn: conn.enable() hostname = conn.find_prompt().rstrip("#>") parsed = conn.send_command("show version", use_textfsm=True) config = conn.send_command("show running-config") version = "unparsed" if isinstance(parsed, list) and parsed: version = parsed[0].get("version", "unknown") stamp = datetime.now().strftime("%Y%m%d-%H%M%S") (BACKUP_DIR / f"{hostname}_{stamp}.cfg").write_text(config) return hostname, version def main(): failures = [] for row in load_devices("devices.csv"): host = row["host"] try: hostname, version = backup_device(host) print(f"OK {host:15} {hostname:20} {version}") except (NetmikoTimeoutException, NetmikoAuthenticationException) as exc: print(f"FAIL {host:15} {type(exc).__name__}") failures.append(host) if failures: print(f"\n{len(failures)} device(s) failed: {', '.join(failures)}") if __name__ == "__main__": main() ``` ### What the script is doing A few details are worth understanding rather than copying blindly. The device_type value tells Netmiko which driver to use; cisco_ios covers both IOS and IOS-XE. The with block guarantees the SSH session closes even if a command fails, which matters because many devices limit the number of concurrent VTY sessions. The use_textfsm=True argument asks Netmiko to parse the output with a TextFSM template; when a template exists you get a list of dictionaries, and when it does not you get the raw string back, which is why the script checks the type before reading the version. Error handling is the difference between a demo and a tool. Without the try/except, one unreachable switch would stop the entire run and leave you guessing which devices were backed up. Catching the specific timeout and authentication exceptions lets the script finish and report exactly which hosts need attention. Run it with credentials in environment variables so you are not typing them every time: ``` export NET_USER=netadmin read -s NET_PASS && export NET_PASS python backup.py ``` ### Making a change with Netmiko Pushing configuration is just as simple. The send_config_set() method enters configuration mode, sends each line, and exits again; save_config() writes the running configuration to startup: ``` commands = [ "ntp server 192.0.2.123", "logging host 192.0.2.60", ] with ConnectHandler(**device) as conn: conn.enable() output = conn.send_config_set(commands) print(output) conn.save_config() ``` This works, but notice what it does not do: it does not check whether the lines are already present, it does not show you a diff before applying, and it does not tell you whether anything actually changed. You could build all of that yourself, and many engineers do. For standard configuration tasks, though, Ansible already provides it. ## From script to tool: habits that scale Before moving on to Ansible, it is worth adopting a few habits that will make every script you write more trustworthy. None of them require advanced Python. - Separate data from logic. Device lists, NTP servers and VLAN definitions belong in CSV or YAML files, not hardcoded in the script. When the data changes, the code should not need to. - Log what you did. Print or write a log line for every device: success, failure and what changed. When someone asks next month why a switch has a new syslog server, you want an answer. - Add a dry-run flag. A simple --dry-run argument that prints commands instead of sending them catches mistakes before they reach a device. - Parallelize carefully. A thread pool with five to ten workers turns a fifteen-minute serial backup into a two-minute job, but do not hammer TACACS+ servers or slow control planes with hundreds of simultaneous logins. - Prefer structured output. Parsing raw text with string slicing breaks the first time a vendor changes a column width. TextFSM templates, or APIs that return JSON, are far more robust. Pro tip: Schedule your backup script with cron or a systemd timer, write the configs into a Git repository, and commit after every run. You get a free configuration history: git diff between two days shows exactly what someone changed on a switch, even if they forgot to tell anyone. ## Ansible for network devices: inventory and variables Ansible is an agentless automation engine. For servers it typically copies Python modules to the target and runs them there, but network devices cannot run Python, so network modules execute on your workstation (the control node) and talk to devices over SSH or an API. That is why network playbooks use a special connection type and why the ansible_network_os variable matters: it tells Ansible which platform plugins to load. ### Project layout A small, conventional layout keeps everything predictable: ``` net-automation/ ├── ansible.cfg ├── inventory/ │ ├── hosts.yml │ └── group_vars/ │ └── ios/ │ ├── vars.yml │ └── vault.yml ├── playbooks/ │ ├── backup.yml │ └── baseline.yml ├── backup.py ├── devices.csv └── requirements.txt ``` The ansible.cfg file tells Ansible where the inventory is, so you do not need to pass -i on every run: ``` [defaults] inventory = inventory/hosts.yml retry_files_enabled = False interpreter_python = auto_silent [persistent_connection] command_timeout = 60 ``` ### The inventory The inventory lists your devices and groups them. Groups are where the power comes from: you can target all access switches, a single site, or every IOS device with one word. YAML inventories are easier to read than the older INI format once you have nested groups: ``` all: children: ios: children: core: hosts: core-sw1: ansible_host: 192.0.2.1 access: hosts: acc-sw1: ansible_host: 192.0.2.11 acc-sw2: ansible_host: 192.0.2.12 ``` Connection settings and shared data live in group_vars. Every host in the ios group inherits these values: ``` # inventory/group_vars/ios/vars.yml ansible_network_os: cisco.ios.ios ansible_connection: ansible.netcommon.network_cli ansible_user: "{{ vault_net_user }}" ansible_password: "{{ vault_net_pass }}" ansible_become: true ansible_become_method: enable ansible_become_password: "{{ vault_net_pass }}" ntp_servers: - 192.0.2.123 - 192.0.2.124 syslog_host: 192.0.2.60 ``` The credentials themselves live in vault.yml, encrypted with ansible-vault. Create it with ansible-vault create inventory/group_vars/ios/vault.yml and add the two vault_ variables. The file on disk is ciphertext, so it can be committed safely as long as the vault password itself is not. Prefixing vaulted variables with vault_ and referencing them from a plain file is a common convention that makes it obvious where a value comes from. Test connectivity before writing any playbook: ``` ansible ios -m cisco.ios.ios_command -a "commands='show clock'" --ask-vault-pass ``` ## Writing your first playbook A playbook is a YAML file that describes which hosts to target and which tasks to run, in order. The playbook below gathers basic facts, then ensures every IOS device has the standard NTP servers, syslog host and log timestamps, and saves the configuration only when something actually changed. ``` --- - name: Apply NTP and logging baseline to IOS devices hosts: ios gather_facts: false tasks: - name: Gather minimal device facts cisco.ios.ios_facts: gather_subset: min - name: Report software version ansible.builtin.debug: msg: "{{ inventory_hostname }} runs {{ ansible_net_version }}" - name: Configure NTP servers cisco.ios.ios_config: lines: - "ntp server {{ item }}" loop: "{{ ntp_servers }}" notify: Save configuration - name: Configure logging cisco.ios.ios_config: lines: - service timestamps log datetime msec localtime show-timezone - "logging host {{ syslog_host }}" notify: Save configuration handlers: - name: Save configuration cisco.ios.ios_config: save_when: modified ``` Several important ideas are packed into those lines. Module names are fully qualified (cisco.ios.ios_config rather than just ios_config), which avoids ambiguity when several collections are installed. The ios_config module compares the lines you supply against the running configuration and only sends the ones that are missing, so running the playbook twice produces "changed" the first time and "ok" the second. That property is called idempotence, and it is the main reason to use Ansible rather than a loop of raw commands. The handler runs once at the end of the play, and only if at least one task reported a change; save_when: modified then writes memory only if running and startup configurations differ. Watch out: ios_config matches your lines against the text of the running configuration. If you push a command that IOS stores in a different form, or a default that never appears in show running-config, the task reports "changed" on every run. When that happens, check how the device actually displays the line and write it exactly that way. ### Resource modules: declare the state, not the commands For common features, the cisco.ios collection also provides resource modules that work with structured data instead of CLI lines. With ios_vlans, you describe the VLANs you want and the module works out the commands: ``` - name: Ensure standard VLANs exist on access switches cisco.ios.ios_vlans: config: - vlan_id: 10 name: USERS - vlan_id: 20 name: VOICE - vlan_id: 99 name: MGMT state: merged ``` The state parameter controls behavior: merged adds or updates what you list, replaced makes each listed VLAN match exactly, overridden removes anything not in your list, and deleted removes what you specify. Treat overridden with great respect; it is exactly what you want for a fully managed device and exactly what you do not want when someone has added a VLAN by hand that the file does not know about. If VLAN design is still new to you, review VLANs explained before automating it. ### Run it safely ``` ansible-playbook playbooks/baseline.yml --check --diff --limit acc-sw1 --ask-vault-pass ansible-playbook playbooks/baseline.yml --limit acc-sw1 --ask-vault-pass ansible-playbook playbooks/baseline.yml --limit access --ask-vault-pass ``` Check mode with --diff shows what would change without touching the device. Limiting to a single host, then a single group, then everything, is a simple staged rollout that catches surprises while the blast radius is still small. ## A Git workflow for network changes Once your network is described by scripts, inventories and variables, Git becomes your change history, your review tool and your undo button. You do not need to become a software developer; a handful of commands covers ninety percent of daily use. ### Initialize the repository ``` git init cat > .gitignore <<'EOF' .venv/ __pycache__/ *.retry .vault_pass backups/ EOF git add . git commit -m "Initial automation project: inventory, baseline playbook, backup script" ``` Ignoring backups/ keeps device configs out of your code repository; store those in a separate, access-controlled repository, because running configurations contain password hashes, SNMP settings and other sensitive details. ### Branch, review, merge Treat every change as a short-lived branch. The workflow looks like this: - Create a branch named after the change: git switch -c change/add-ntp-server. - Edit the variables or playbook, then run it in check mode against a lab or pilot device. - Commit with a message that explains why, not just what: git commit -am "Add second NTP server per new time-source standard". - Push the branch and open a pull request (or merge request) on your Git platform. - A colleague reviews the diff, ideally with the check-mode output pasted into the request. - After approval and within the change window, merge to main and run the playbook from main. The rule that makes this work is simple: production runs only from the main branch. That guarantees what is on the network matches what was reviewed. Add linting with yamllint and ansible-lint, either as pre-commit hooks or as a CI pipeline step, so obvious mistakes such as bad indentation or deprecated module names are caught before a human even looks at the change. Pro tip: Reference your change ticket number in the branch name or commit message. Months later, git log --grep takes you straight from a ticket to the exact lines that changed, and from a line back to the ticket. ## Testing and rolling out changes safely Automation amplifies whatever you give it. A correct change reaches the whole network in minutes, and so does a wrong one. A few guardrails keep you out of trouble: - Always back up first. Run your backup script or a backup playbook immediately before any change run, so you have a known-good config to compare or restore. - Protect management access. Be extra careful with changes to VTY lines, AAA, management ACLs or the management VLAN. If a change locks you out, automation cannot fix it. On IOS, reload in 10 before a risky change gives you a scheduled rollback if you lose access; cancel it with reload cancel once you confirm the device is reachable. - Use serial batches. Ansible's serial keyword runs a play against a few hosts at a time, and max_fail_percentage stops the run if too many fail. - Verify, do not assume. Add tasks after the change that run show commands and assert the expected state, for example that NTP is synchronized or that an interface is up. - Know your troubleshooting process. When an automated change causes an issue, the same disciplined approach applies as with manual changes; see our network troubleshooting methodology. ### Where to go next Once these basics feel comfortable, the natural next steps are templating full configurations with Jinja2, adopting a source of truth such as an IPAM or DCIM platform that feeds your inventory dynamically, and exploring model-driven interfaces such as NETCONF and RESTCONF on platforms that support them. Each step builds on the same foundations: clean data, idempotent tasks, version control and staged rollouts. Automation is also one of the clearest skills that separates an administrator from an engineer, which is why it features prominently on the road from network admin to network engineer. ## Key takeaways - Start with read-only automation such as backups and audits; it delivers value with almost no risk. - Netmiko handles SSH sessions, prompts and paging, so a short Python script can back up or query an entire network. - Ansible with the cisco.ios collection and network_cli gives you idempotent configuration, check mode and diffs out of the box. - Keep data in inventories and variables, keep secrets in ansible-vault or environment variables, and never commit passwords. - Use Git branches and reviews for every change, and run production only from the main branch. - Roll out in stages: one lab or pilot device, then one group, then everything. Automation works best on a network that is already consistent and well understood. If you are not sure where your network stands, a Network Health Assessment identifies the configuration drift, gaps and quick wins worth automating first. Have a specific automation project in mind? Get in touch and let us talk it through. ## FAQ Q: Should I learn Python or Ansible first for network automation? A: Learn enough Python to read and modify a short script first, because it teaches you how connections, data structures and errors work. Then move to Ansible for repeatable configuration tasks. Most working engineers use both: Python for custom data gathering and Ansible for declarative, idempotent configuration. Q: Is Netmiko still relevant now that devices have APIs? A: Yes. Netmiko works over SSH and screen-scrapes the CLI, so it runs against almost any device you already own, including older switches without NETCONF or RESTCONF. For newer platforms, API-based tools give structured data, but Netmiko remains the fastest way to automate a mixed, real-world estate. Q: Which Ansible connection type should I use for Cisco IOS? A: Use ansible.netcommon.network_cli with ansible_network_os set to cisco.ios.ios. It runs over SSH, supports privilege escalation with become and become_method enable, and works with all the cisco.ios modules, including ios_config, ios_command, ios_facts and the resource modules such as ios_vlans. Q: How do I keep passwords out of my automation repository? A: Never hardcode them. Use environment variables or an interactive prompt for scripts, encrypt Ansible variables with ansible-vault, and add secret files to .gitignore. Better still, use per-user accounts authenticated through TACACS+ or RADIUS so every automated change is attributed to a real person. Q: Can automation break my network? A: Automation can make the same mistake on a hundred devices in seconds, so build safety in from day one: start with read-only tasks, use check mode and diff, limit runs to a single lab or pilot device first, review changes through pull requests, and always keep a fresh configuration backup before pushing. --- # Network Documentation People Actually Use: Diagrams, IPAM and Runbooks URL: https://roadtoneteng.com/network-documentation-guide/ Updated: 2026-10-14 Every network has documentation. The question is whether anyone trusts it. Too often it is a diagram from the original installation, a spreadsheet with three conflicting tabs and a folder of notes only one person understands. When an outage hits, nobody opens any of it, because experience has taught them it is wrong. This guide shows you how to build a small, focused set of network documentation, from diagrams and IP address management to runbooks, that people actually use because it is accurate, findable and maintained as part of everyday work. ## Why network documentation fails Documentation rarely fails because people are lazy. It fails because of how it is produced. Understanding the failure modes helps you design something that survives. - It is a project, not a process. Someone spends two weeks documenting everything, then moves on. Six months of undocumented changes later, the diagrams are fiction. - It tries to capture everything. A diagram that shows every access port, every VLAN and every route on one page is unreadable, so people stop looking at it. - It lives in the wrong place. Files on a personal laptop, attachments in old tickets, or a file share that goes down with the network you are trying to fix. - Nobody owns it. If everyone is responsible for updating the IP plan, nobody is. - It duplicates data. The same subnet appears in a spreadsheet, a diagram and a firewall object list, each with a slightly different description. When they disagree, all of them lose credibility. The fix is to document less, but better: a small number of artifacts, each with a clear purpose, a clear owner and a clear trigger for updates. Think of documentation as part of the network itself. A change is not finished until the documentation reflects it. Note: Good documentation also has a career payoff. Engineers who can explain a network clearly on one page are trusted with bigger designs. It is one of the habits that most clearly separates a network engineer from someone who simply keeps the network running. ## What to document: the minimum useful set Start with the artifacts that answer the questions people actually ask during outages, audits and projects. For most small and mid-sized networks, the following set covers the vast majority of needs: Artifact | Answers the question | Typical owner | Update trigger | Physical (L1) diagram | What is plugged into what, and where is it? | Infrastructure lead | Any cabling, rack or hardware change | Logical (L2/L3) diagram | How does traffic flow between VLANs, subnets and sites? | Network engineer | New VLAN, subnet, route or site | IP address plan (IPAM) | Which subnets exist and which addresses are free? | Network engineer | Every allocation or decommission | Device inventory | What do we own, what software runs on it, when does support end? | Operations | Purchase, replacement, upgrade | Circuit and vendor register | Who do we call when the internet link is down, and with which circuit ID? | Operations | Contract or circuit change | Runbooks | How do we perform this task or recover from this failure? | Task owner | Process change or lessons learned | Standards | How should a new switch, VLAN or firewall rule be configured and named? | Network lead | Design decision | Credentials deserve a special mention: they belong in a password manager with shared vaults and access logging, never in a diagram, spreadsheet or wiki page. Your documentation should say where the credential is, not what it is. ## Network diagrams that communicate A diagram has one job: to let someone build a correct mental model of the network quickly. That means every diagram needs a specific audience and a specific layer. Trying to serve everyone on one page serves no one. ### Separate the layers The most useful split is by OSI layer, because each layer answers different questions: - Physical (Layer 1): racks, devices, patch panels, physical links with interface names, cable types and speeds. This is what a field technician needs to replace a failed optic or trace a cable. Rack elevations belong here too. - Data link (Layer 2): switches, trunks, port-channels, VLANs carried on each trunk, spanning-tree root placement and first-hop redundancy pairs. This is what you need when a VLAN does not reach a closet or when a loop appears. - Network (Layer 3): routers, firewalls and layer 3 switches, subnets on each segment, routing protocol areas or autonomous systems, default routes, VPN tunnels and NAT boundaries. This is what you need for any reachability problem. For multi-site networks, add a high-level overview showing sites, WAN circuits and internet breakouts with almost no detail, then link down to per-site diagrams. That hierarchy mirrors how people troubleshoot: from broad to specific. ### Conventions that make diagrams readable - Use a consistent symbol set and a legend on every page. Neutral, generic shapes for router, switch, firewall and access point are fine; consistency matters more than style. - Label links at both ends with interface names, for example Gi1/0/49 to Te1/1/1. Add speed and, for port-channels, the channel number. - Label subnets on segments with network address and prefix length plus VLAN ID and name, for example VLAN 20 USERS 10.20.20.0/24. - Flow top to bottom or left to right: internet and WAN at the top, core in the middle, access at the bottom. Avoid crossing lines. - Add a title block with diagram name, scope, version or date, and owner. A diagram without a date cannot be trusted. - Do not show every access port. Represent a stack of access switches as one object with a note, and leave endpoint detail to the IPAM or switch port data. If you are documenting VLANs, keep the VLAN-to-subnet mapping consistent with the design principles in VLANs explained; a diagram is a great place to spot an inconsistent trunk. ### Gather the truth from the network Draw diagrams from live data, not memory. Neighbor discovery protocols show exactly what is connected to what: ``` show cdp neighbors detail show lldp neighbors detail show etherchannel summary show interfaces trunk show spanning-tree root show ip route show ip interface brief ``` Run these on every infrastructure device and you have the raw material for both the L2 and L3 diagrams. Better yet, collect them automatically with a short script; the techniques in our network automation guide make this a five-minute job instead of an afternoon. Pro tip: Use a diagramming tool that saves to a text-friendly or open format, and store the source files alongside exported PDFs. A PNG with no source file is a dead end the first time something changes. ## IP address management that stays accurate IP address management, or IPAM, is the single most-referenced piece of network documentation. It is also the most frequently wrong, because addresses are allocated in a hurry and rarely released. An accurate IPAM prevents duplicate addresses, makes firewall rule reviews possible and turns new-site planning from guesswork into arithmetic. ### Design the plan before recording it IPAM records a plan; it does not replace one. A good IPv4 plan allocates address space hierarchically, for example a block per site, then a block per function within each site, so that summarization and firewall policy stay simple. A typical structure for a private network might look like this: Scope | Example prefix | Notes | Organization | 10.0.0.0/8 | Private space per RFC 1918 | Site (HQ) | 10.10.0.0/16 | Second octet identifies the site | Users VLAN 20 | 10.10.20.0/24 | Third octet matches VLAN ID where practical | Voice VLAN 30 | 10.10.30.0/24 | Separate DHCP scope and QoS policy | Infrastructure mgmt VLAN 99 | 10.10.99.0/24 | Switches, APs, UPS management | Point-to-point links | 10.10.255.0/24 | Carved into /31s per RFC 3021 | Loopbacks | 10.10.254.0/24 | /32 per device, used as router ID and management source | Matching the third octet to the VLAN ID is not a technical requirement, but it removes an entire class of mistakes and makes troubleshooting faster. If you need a refresher on carving blocks into subnets, see subnetting made simple or use the subnet calculator in our network tools. Plan IPv6 alongside IPv4 from the start, even if you deploy it later. ### What to record for each subnet and address - Per subnet: prefix, VLAN ID and name, site, purpose, gateway address, DHCP scope range and server, DNS servers, owner and any security zone it belongs to. - Per static address: IP, hostname, device type, MAC address where useful, owner, and a reference to the ticket or change that allocated it. - Reservations: mark gateway, first-hop redundancy virtual addresses and reserved ranges so they are never handed out by mistake. ### Spreadsheet or dedicated IPAM? A spreadsheet can work for one site with a single owner. Beyond that, a dedicated IPAM tool, whether open-source or commercial, earns its keep: it prevents overlapping prefixes, calculates utilization, keeps an audit trail and exposes an API. That API is the turning point, because it lets your IPAM become a source of truth that feeds automation, monitoring and even DHCP and DNS. When automation reads its inventory from the same place humans update, the documentation and the network stop drifting apart. Watch out: Do not let the IPAM and the network silently disagree. Schedule a regular reconciliation that compares IPAM records against ARP tables, DHCP leases and DNS. Addresses that are in use but not recorded, or recorded but not seen for months, should be investigated and cleaned up. ## Naming conventions and labels Names are documentation you see every day: in prompts, in logs, in monitoring alerts and on cable labels. A good naming convention lets anyone decode a device name without looking it up. A practical format encodes site, role and a sequence number, kept short enough to fit in prompts and monitoring dashboards: Example name | Decoded | hq-core-sw01 | Headquarters, core layer, switch number 1 | hq-fl2-acc-sw03 | Headquarters, second floor, access switch number 3 | br1-edge-fw01 | Branch 1, internet edge, firewall number 1 | dc-ap-wl012 | Data center site, wireless access point number 12 | Whatever format you choose, write it down in your standards document, use lowercase, avoid characters that cause trouble in DNS or scripts, and apply it everywhere: hostnames, DNS records, monitoring and the IPAM. Consistent interface descriptions are equally valuable. A description such as UPLINK hq-core-sw01 Te1/0/1 or AP dc-ap-wl012 turns show interfaces description into a live connectivity map. Physical labels on cables and patch panels follow the same logic; our article on structured cabling and fiber basics covers patch panel labeling in detail. ## Runbooks that work at 3 a.m. A runbook is a step-by-step procedure for a specific task or failure scenario. Its reader is tired, stressed and possibly not the person who wrote it. Every design choice should serve that reader. ### What deserves a runbook You do not need a runbook for everything. Write them for tasks that are infrequent but critical, risky, or likely to be performed by someone less experienced: - Failing over to the backup internet circuit and failing back. - Replacing a failed stack member or a failed firewall in a high-availability pair. - Restoring a device from a configuration backup. - Responding to a suspected broadcast storm or switching loop. - Onboarding a new branch office or adding a VLAN end to end. - Rotating a pre-shared key or renewing a VPN certificate. ### A runbook template - Title and purpose: one sentence describing when to use this runbook. - Scope and impact: which systems are affected and whether users will notice. - Prerequisites: access required, tools, backups to take, approvals or change window. - Procedure: numbered steps with exact commands and the expected output after each one. - Verification: how to confirm success, including the specific show commands or tests to run. - Rollback: how to undo the change and at what point you should decide to roll back. - Escalation: who to contact, including vendor support numbers and circuit IDs. - Metadata: owner, last tested date and a link to related diagrams. The single most important field is "last tested." A runbook that has never been followed is a hypothesis. Walk through each critical runbook at least once a year, ideally during a planned maintenance window, and fix every step that was unclear. When you troubleshoot a real incident, capture what worked and turn it into a runbook update, so that every outage leaves the team better prepared for the next one. Pro tip: Link runbooks directly from your monitoring alerts. When an alert fires for a down WAN circuit, the notification should include the link to the WAN failover runbook. That one link removes the "where is the procedure?" step from every incident. ## Keeping documentation current Accuracy is the only feature that matters; out-of-date documentation is worse than none because it sends people in the wrong direction with confidence. Keeping it current is a matter of process, not willpower. - Make documentation part of the change. Add "documentation updated" as a required field in your change tickets. The change is not closed until the diagram, IPAM entry or runbook reflects it. - Assign owners. Each artifact has one named role responsible for it. Others contribute; the owner reviews. - Automate collection. Configuration backups, device inventories with serials and software versions, and neighbor tables can all be gathered automatically. The less you type by hand, the less can be wrong. - Use monitoring as a cross-check. Your monitoring platform discovers devices and interfaces continuously. Compare its view against your inventory; see network monitoring 101 for setting that up. - Review quarterly. Spend an hour each quarter comparing diagrams with live neighbor data, reconciling the IPAM and checking support end dates in the inventory. - Version everything. Keep text, diagram sources and standards in a wiki with history or a Git repository, so you can see who changed what and when. ## Where to keep it all The right tool is the one your team will actually open. In practice, most organizations combine a few complementary systems: - Wiki or Git repository for standards, runbooks and diagram sources, with search and change history. - IPAM and DCIM tooling for structured data such as prefixes, addresses, racks, devices and cables, ideally with an API. - Password manager with shared vaults for device, vendor portal and break-glass credentials. - Ticketing or ITSM system for changes and incidents, linked to the documentation they touch. Two practical rules apply to all of them. First, make sure documentation is reachable when the network is not; a wiki hosted on a server behind the core switch is useless when the core switch fails. Keep an exported, encrypted offline copy of critical diagrams, the circuit register and key runbooks. Second, control access sensibly. Diagrams and IP plans are valuable to an attacker, so treat them as internal, but do not lock them down so tightly that the on-call engineer cannot reach them. ## Key takeaways - Document less but better: a focused set of diagrams, IPAM, inventory, circuit register, runbooks and standards. - Separate physical, Layer 2 and Layer 3 diagrams, label both ends of every link, and date every diagram. - Design the IP plan hierarchically, then record it in an IPAM that you reconcile against live data. - Use a decodable naming convention everywhere, from hostnames to interface descriptions and cable labels. - Write runbooks for rare, critical tasks, include verification and rollback, and test them regularly. - Make documentation a required step of every change, assign owners and automate data collection wherever possible. If your documentation is scattered, outdated or missing entirely, you do not have to start from a blank page. Our Network Documentation & Diagram Package delivers verified diagrams, an IP plan and inventory built from your live network, ready for your team to maintain. Questions about your specific environment? Contact us. ## FAQ Q: What is the minimum network documentation a small business needs? A: At minimum: a physical (Layer 1) diagram of racks and links, a logical Layer 2/Layer 3 diagram showing VLANs, subnets and routing, an IP address plan, a device inventory with serial numbers and support dates, credentials stored in a password manager, ISP circuit details, and runbooks for the few tasks that happen during outages. Q: Is a spreadsheet good enough for IP address management? A: For a single site with a handful of subnets, a well-structured spreadsheet can work if one person owns it. Once you have multiple sites, frequent changes or more than one admin, a dedicated IPAM tool pays off because it enforces uniqueness, tracks utilization, records history and can feed automation. Q: How often should network diagrams be updated? A: Diagrams should be updated as part of every change that alters topology, addressing or routing, not on a calendar. Add a documentation step to your change process, then run a quarterly review that compares diagrams against live data such as CDP or LLDP neighbors and routing tables. Q: What should a network runbook contain? A: A good runbook states its purpose and when to use it, prerequisites and required access, numbered steps with exact commands, the expected output at each step, how to verify success, how to roll back, and who to escalate to. It should be short enough to follow under pressure. Q: Where should network documentation be stored? A: Store it somewhere that is searchable, access-controlled, backed up and reachable during an outage. A wiki or Git repository for text and diagrams, an IPAM or DCIM tool for structured data, and a password manager for credentials is a common combination. Keep an offline copy of critical runbooks. --- # IPv6 for Network Admins: Addressing, SLAAC, DHCPv6 and a Practical Transition Plan URL: https://roadtoneteng.com/ipv6-for-network-admins/ Updated: 2026-10-14 IPv6 is not a future project. Every modern operating system enables it by default, most mobile networks and many residential ISPs already run it at scale, and a growing share of internet traffic uses it. If you have not deployed IPv6 deliberately, your endpoints are still using it on every LAN segment, at least with link-local addresses, which means it is already part of your attack surface. This guide gives network admins the practical knowledge to take control: address types and their prefixes, a sensible addressing plan, how SLAAC and DHCPv6 really interact, working Cisco IOS configuration, essential security controls, and a phased transition plan. ## Why IPv6 deserves your attention now The regional internet registries have long since exhausted their free pools of IPv4 addresses. Organizations now buy IPv4 space on a transfer market or share addresses behind carrier-grade NAT, which complicates logging, geolocation and inbound services. Meanwhile, IPv6 delivers a virtually unlimited supply of globally routable addresses and removes the need for NAT as an addressing workaround. For network admins, three practical reasons stand out: - It is already on your network. Windows, macOS, Linux, iOS and Android all prefer IPv6 when it is available. An unauthorized device sending Router Advertisements can quietly become the IPv6 default gateway for an entire VLAN. - Your users may already be on IPv6 at home and on mobile. Remote access, cloud services and customer-facing applications need to work for them. - It is a career skill. IPv6 appears on certification blueprints and in design interviews, and engineers who can plan and deploy it confidently are in short supply. ## IPv6 address format and notation An IPv6 address is 128 bits long, written as eight groups of four hexadecimal digits separated by colons. Each group, sometimes called a hextet, represents 16 bits. Two rules shorten addresses, and RFC 5952 defines the canonical text form that tools and documentation should use: - Leading zeros in each group can be omitted: 0db8 becomes db8, 0000 becomes 0. - One run of two or more consecutive all-zero groups can be replaced with ::. If there are several runs, compress the longest; if they tie, compress the first. Use :: only once per address. - Write hexadecimal letters in lowercase. So 2001:0db8:0000:0000:0000:ff00:0042:8329 becomes 2001:db8::ff00:42:8329. Consistent formatting matters more than it seems: searching logs, IPAM and firewall configurations for an address only works if everyone writes it the same way. Every address splits into a network prefix and an interface identifier. On a LAN the split is almost always at bit 64: the first 64 bits identify the subnet, and the last 64 bits identify the interface. Prefix lengths use the same CIDR notation as IPv4, for example 2001:db8:acad:20::/64. If CIDR still feels shaky, revisit subnetting made simple; the concepts carry over directly, only the numbers are bigger and the arithmetic is in hexadecimal. ## IPv6 address types and prefixes IPv6 has no broadcast addresses. Functions that used broadcast in IPv4, such as ARP, use multicast instead. The address architecture is defined in RFC 4291, with several later RFCs adding special-purpose ranges. These are the types you will meet daily: Type | Prefix | Purpose | Reference | Global unicast (GUA) | 2000::/3 | Globally routable addresses assigned by ISPs and registries | RFC 4291 | Link-local | fe80::/10 (used as fe80::/64) | Automatically configured on every IPv6 interface; never routed; used by NDP and routing protocols | RFC 4291 | Unique local (ULA) | fc00::/7 (in practice fd00::/8) | Private addressing; fd00::/8 with a random 40-bit Global ID | RFC 4193 | Multicast | ff00::/8 | One-to-many delivery; replaces broadcast | RFC 4291 | Loopback | ::1/128 | The local host, equivalent to 127.0.0.1 | RFC 4291 | Unspecified | ::/128 | No address yet; source of Duplicate Address Detection probes | RFC 4291 | IPv4-mapped | ::ffff:0:0/96 | Represents IPv4 addresses inside dual-stack software | RFC 4291 | NAT64 well-known prefix | 64:ff9b::/96 | Embeds IPv4 addresses for NAT64 translation | RFC 6052 | Documentation | 2001:db8::/32 | Reserved for examples and documentation, never routed | RFC 3849 | A few points trip people up. Every IPv6 interface always has a link-local address, even when it also has one or more global addresses, and having multiple addresses per interface is normal, not a misconfiguration. Site-local addresses (fec0::/10) were deprecated by RFC 3879 and should not be used. Anycast addresses have no special prefix; they are ordinary unicast addresses assigned to more than one interface. ### Multicast addresses you should recognize - ff02::1: all nodes on the link. - ff02::2: all routers on the link; hosts send Router Solicitations here. - ff02::1:ff00:0/104: solicited-node multicast, built from the last 24 bits of a unicast address and used by Neighbor Discovery instead of ARP broadcasts. - ff02::1:2: all DHCPv6 relay agents and servers. - ff02::5 and ff02::6: OSPFv3 routers and designated routers, covered in our OSPF fundamentals article. The ff02 prefix means link-local scope; such packets never leave the segment. Other scopes exist, such as ff05 for site-local multicast. ## Building an IPv6 addressing plan The biggest mental shift with IPv6 is that you stop conserving addresses and start designing for clarity. In IPv4 you size each subnet to the number of hosts. In IPv6 every LAN gets a /64, regardless of whether it holds three devices or three thousand, and you plan for readable, summarizable structure instead. ### How much space you get RFC 6177 recommends that end sites receive enough space for multiple subnets and leaves the exact size to operators; in practice businesses typically receive a /48 and smaller sites or residential customers often receive a /56. The arithmetic is simple because each 4-bit nibble is one hexadecimal digit: Allocation | Number of /64 subnets | Typical use | /48 | 65,536 | A business site or small enterprise | /52 | 4,096 | A large site carved from a larger block | /56 | 256 | A branch office or residential customer | /60 | 16 | A small branch or some residential services | /64 | 1 | A single LAN segment | Multi-site organizations usually request provider-independent space from their regional internet registry, then assign a /48 per site so each location can be summarized as a single route. ### Design on nibble boundaries Assign meaning to hexadecimal digits so that an address tells you where it lives. With a /48 per site, the fourth hextet gives you 16 bits to structure subnets. A readable scheme for a site with prefix 2001:db8:acad::/48 could be: - 2001:db8:acad:0::/64: reserved; not used for hosts. - 2001:db8:acad:10::/64, :20::/64, :30::/64: user, voice and server VLANs 10, 20 and 30. The hextet is hexadecimal, but writing the VLAN number there makes it instantly readable. - 2001:db8:acad:99::/64: management VLAN 99. - 2001:db8:acad:fff0::/64: loopbacks, assigned as /128s. - 2001:db8:acad:ffff::/64 range: point-to-point links, each configured as a /127 per RFC 6164, with a full /64 reserved per link for simplicity. Record the plan in your IPAM from day one, alongside the IPv4 plan. Our network documentation guide covers how to keep that IPAM accurate. Pro tip: Mirror your IPv4 structure where it helps. If VLAN 20 is 10.10.20.0/24 in IPv4, making it 2001:db8:acad:20::/64 in IPv6 means anyone can map one to the other without looking anything up. ## Neighbor Discovery and SLAAC IPv6 hosts learn almost everything about their network from the router, through the Neighbor Discovery Protocol (NDP) defined in RFC 4861. NDP uses ICMPv6 messages that replace ARP, router discovery and redirects: ICMPv6 type | Message | Role | 133 | Router Solicitation (RS) | Host asks routers to announce themselves | 134 | Router Advertisement (RA) | Router announces prefixes, flags, default gateway and lifetimes | 135 | Neighbor Solicitation (NS) | Resolves an address to a MAC address; also used for Duplicate Address Detection | 136 | Neighbor Advertisement (NA) | Answers a Neighbor Solicitation | 137 | Redirect | Tells a host about a better first hop | ### How SLAAC works Stateless Address Autoconfiguration, specified in RFC 4862, lets a host build its own global address with no server involved: - The host creates a link-local address and verifies it is unique with Duplicate Address Detection (DAD), sending a Neighbor Solicitation from the unspecified address ::. - It sends a Router Solicitation to ff02::2, or waits for the next periodic Router Advertisement. - The RA contains a Prefix Information option, for example 2001:db8:acad:20::/64, with the autonomous (A) flag set. - The host combines that prefix with a 64-bit interface identifier it generates, runs DAD again, and starts using the address. - The router's link-local source address in the RA becomes the host's default gateway. The interface identifier used to be derived from the MAC address using modified EUI-64: the MAC is split in half, fffe is inserted in the middle and the universal/local bit is inverted. Because that exposes the hardware address and allows tracking across networks, modern operating systems instead use stable, opaque identifiers per RFC 7217 and additional temporary addresses for outbound connections per RFC 8981. Expect to see several global addresses on a typical client, some of which change daily. DNS server information can be delivered in the RA itself through the RDNSS option defined in RFC 8106, which most modern clients support. That makes pure SLAAC viable on many networks without any DHCPv6 at all. ## DHCPv6: stateless, stateful and prefix delegation DHCPv6, now consolidated in RFC 8415, uses UDP port 546 on clients and 547 on servers and relays. It is not just DHCP with longer addresses, and two differences matter. First, DHCPv6 never provides the default gateway; that always comes from Router Advertisements. Second, clients identify themselves with a DHCP Unique Identifier (DUID), not their MAC address, which affects reservations and how you correlate logs. Two flags in the Router Advertisement tell hosts what to do, and the A flag in the prefix option controls SLAAC: Mode | M flag | O flag | A flag | Address from | DNS and options from | SLAAC only | 0 | 0 | 1 | SLAAC | RA (RDNSS) | SLAAC + stateless DHCPv6 | 0 | 1 | 1 | SLAAC | DHCPv6 | Stateful DHCPv6 | 1 | (implied) | 0 | DHCPv6 | DHCPv6 | Stateful DHCPv6 is attractive to admins who want a lease table showing which device has which address, but be aware that client support is not universal. Notably, Android does not implement stateful DHCPv6 address assignment, so a segment that relies on it alone will leave Android devices without a global address. A common compromise is SLAAC with stateless DHCPv6 on user and guest VLANs, and static or stateful addressing on server and infrastructure segments where you control the operating systems. ### Prefix delegation DHCPv6 Prefix Delegation (DHCPv6-PD) lets a router request an entire prefix, such as a /56 or /48, from an upstream router. ISPs use it to hand prefixes to customer edge routers, which then carve /64s for their LANs. If your branch internet service is IPv6-enabled, prefix delegation is often how you receive your space, so check whether the delegated prefix is static or can change; changing prefixes complicate firewall rules and DNS. ## Configuring IPv6 on Cisco IOS The configuration below enables IPv6 routing, sets up a user VLAN with SLAAC plus stateless DHCPv6, a managed VLAN with stateful DHCPv6, and a static default route to the ISP. On some Catalyst switches you must first select an SDM template that allocates hardware resources for IPv6, followed by a reload. ``` ipv6 unicast-routing ! ipv6 dhcp pool USERS-STATELESS dns-server 2001:db8:acad:99::53 domain-name corp.example.com ! ipv6 dhcp pool MANAGED-STATEFUL address prefix 2001:db8:acad:30::/64 dns-server 2001:db8:acad:99::53 domain-name corp.example.com ! interface Vlan20 description USERS - SLAAC plus stateless DHCPv6 ipv6 address 2001:db8:acad:20::1/64 ipv6 nd other-config-flag ipv6 dhcp server USERS-STATELESS ! interface Vlan30 description MANAGED - stateful DHCPv6 ipv6 address 2001:db8:acad:30::1/64 ipv6 nd managed-config-flag ipv6 nd prefix 2001:db8:acad:30::/64 no-autoconfig ipv6 dhcp server MANAGED-STATEFUL ! interface GigabitEthernet0/0/0 description WAN - ISP ipv6 address 2001:db8:ffff:1::2/64 ! ipv6 route ::/0 2001:db8:ffff:1::1 ``` If the DHCPv6 server is elsewhere, replace the ipv6 dhcp server line on the SVI with ipv6 dhcp relay destination followed by the server's address. Verify with these commands: ``` show ipv6 interface brief show ipv6 interface Vlan20 show ipv6 neighbors show ipv6 route show ipv6 dhcp binding show ipv6 dhcp pool ``` On the client side, ipconfig /all on Windows or ip -6 addr and ip -6 route on Linux show which addresses were configured and which link-local address is being used as the default gateway. Note: show ipv6 interface displays the joined multicast groups, including the solicited-node addresses. It is a quick way to confirm the interface is participating correctly in Neighbor Discovery. ## IPv6 security essentials IPv6 is not inherently more or less secure than IPv4, but it is different, and controls designed for IPv4 do not automatically cover it. Focus on these areas: - RA Guard (RFC 6105). Block Router Advertisements on access ports so only legitimate routers can become a default gateway. Pair it with DHCPv6 Guard to stop rogue DHCPv6 servers. - Do not block all ICMPv6. Neighbor Discovery depends on it, and routers never fragment IPv6 packets in transit, so Path MTU Discovery relies on ICMPv6 Packet Too Big (type 2) messages. RFC 4890 gives detailed recommendations for filtering ICMPv6 at firewalls. - Firewall parity. Every IPv4 rule needs an IPv6 equivalent. A stateful policy that allows outbound and blocks unsolicited inbound traffic protects hosts just as well as NAT did. Our firewall hardening checklist applies to both protocols. - Logging and monitoring. Make sure your syslog, flow collection and security tools parse IPv6 addresses and that your monitoring platform polls and alerts over IPv6 as well. A basic RA Guard configuration on a Catalyst access switch looks like this: ``` ipv6 nd raguard policy HOST-PORTS device-role host ! ipv6 nd raguard policy UPLINKS device-role router ! interface range GigabitEthernet1/0/1 - 48 ipv6 nd raguard attach-policy HOST-PORTS ! interface TenGigabitEthernet1/1/1 ipv6 nd raguard attach-policy UPLINKS ``` Watch out: Even if you never route IPv6, enable RA Guard on access switches. A single device with internet connection sharing enabled, or a malicious host, can advertise itself as an IPv6 router and intercept traffic from every dual-stack client on the VLAN. ## A practical IPv6 transition plan For most organizations, the right strategy is dual-stack: run IPv4 and IPv6 side by side on the same interfaces, as described in RFC 4213, and let applications prefer IPv6 where it works. Clients implement Happy Eyeballs (RFC 8305), which races IPv6 and IPv4 connection attempts so a broken IPv6 path does not stall users. Translation technologies such as NAT64 (RFC 6146) with DNS64 (RFC 6147), and 464XLAT (RFC 6877) on the client side, become relevant when you start building IPv6-only segments. ### Phase 1: Assess and learn - Inventory every network device, firewall, load balancer and critical application for IPv6 support, including management features such as SNMP, syslog and AAA over IPv6. - Build IPv6 into your lab first; our home network lab guide works perfectly for dual-stack practice. - Enable RA Guard and DHCPv6 Guard and add IPv6 rules to firewalls, even before routing it. ### Phase 2: Obtain space and plan - Request address space from your ISP or registry and decide between provider-assigned and provider-independent space. - Write the addressing plan, choose SLAAC, stateless or stateful DHCPv6 per segment type, and record everything in IPAM. ### Phase 3: Edge and public services - Enable IPv6 on internet links and firewalls, then dual-stack public services such as websites, mail and VPN, adding AAAA records only after testing. ### Phase 4: Core and infrastructure - Enable IPv6 on core and distribution layers, run OSPFv3 or add IPv6 address families to existing routing protocols, and make monitoring and logging fully IPv6-aware. ### Phase 5: Users and beyond - Roll out to user VLANs one site or one segment at a time, measuring help-desk tickets and application issues. - Once dual-stack is stable, evaluate IPv6-only segments with NAT64 and DNS64 for new environments where every component supports it. Each phase delivers value on its own, and you can pause between them without leaving the network in a fragile state. ## Key takeaways - IPv6 is already active on your endpoints; manage it deliberately rather than ignoring it. - Know the key prefixes: 2000::/3 global, fe80::/10 link-local, fc00::/7 unique local, ff00::/8 multicast, and 2001:db8::/32 for documentation. - Use a /64 on every LAN, /127 on point-to-point links and /128 for loopbacks, and design on nibble boundaries for readability. - Router Advertisements always provide the default gateway; the M, O and A flags decide between SLAAC, stateless DHCPv6 and stateful DHCPv6. - Deploy RA Guard, allow essential ICMPv6 and keep IPv4 and IPv6 firewall policies in parity. - Transition in phases with dual-stack as the foundation, starting with the edge and public services. Planning IPv6 is much easier with a clear picture of your current network and its readiness. Our Network Health Assessment includes an IPv6 readiness review covering devices, firewalls and addressing. You can also practice prefix math with the calculators in our network tools, or contact us to discuss your transition plan. ## FAQ Q: Why should every IPv6 LAN segment use a /64 prefix? A: SLAAC builds a 64-bit interface identifier, so it only works on a /64. Several other mechanisms and many host implementations assume /64 as well. Using longer prefixes on LANs breaks autoconfiguration for some clients. The main exceptions are point-to-point links, where /127 is recommended by RFC 6164, and loopbacks, which use /128. Q: Does DHCPv6 provide the default gateway? A: No. In IPv6 the default gateway always comes from Router Advertisements sent by the router, using its link-local address. DHCPv6 can provide addresses, DNS servers and other options, but hosts still need Router Advertisements to learn their default route. Q: Should I use unique local addresses (ULA) instead of global addresses internally? A: Usually not as a replacement. Global unicast addresses work end to end without translation and are the standard design. ULAs from fd00::/8 can be useful for isolated networks or stable internal addressing alongside global addresses, but using ULA plus NAT just to mimic IPv4 adds complexity without real security benefit. Q: Is NAT needed for security in IPv6? A: No. NAT was never a security control; a stateful firewall is. With IPv6, a firewall policy that allows outbound connections and blocks unsolicited inbound traffic gives the same protection that most people attribute to NAT, while keeping end-to-end addressing intact. Q: Can I just disable IPv6 if I am not ready for it? A: Disabling it on hosts is not recommended by major operating system vendors and can break features that use it internally. A better interim approach is to manage it: enable RA Guard and DHCPv6 Guard on access switches, monitor for rogue Router Advertisements, and include IPv6 in firewall policies even before you route it. --- # Network Monitoring 101: SNMP, Syslog, NetFlow and Alerts That Matter URL: https://roadtoneteng.com/network-monitoring-101/ Updated: 2026-10-14 If your users are your monitoring system, you find out about problems last, and you find out with the least useful information possible: "the internet is slow." Effective network monitoring flips that around. It tells you a link is saturating before calls start dropping, shows you which application filled the WAN, and records exactly when an interface flapped. This guide covers the three foundational data sources, SNMP, syslog and NetFlow, with secure configuration examples, the ports you need to allow, a syslog severity reference, and a practical approach to alerts that people actually respond to. ## What network monitoring should achieve Before choosing tools or protocols, be clear about the questions monitoring has to answer. Most of them fall into four groups: - Availability: Is the device, link or service up and reachable right now? - Performance: How busy are links and devices? Are there errors, drops, latency or jitter? - Capacity: How is usage trending? When will this WAN circuit or uplink run out of headroom? - Events and security: What changed, who logged in, what failed, and is traffic behaving unusually? Each data source covers some of these questions well and others poorly. SNMP polling is the workhorse for availability, performance and capacity metrics. Syslog and SNMP traps capture events as they happen. Flow data such as NetFlow and IPFIX explains what traffic is on the network and who is sending it. Add basic synthetic checks, such as ICMP reachability and DNS or HTTP tests, and you have a complete picture. None of the three replaces the others, which is why a mature monitoring setup collects all of them and correlates them by time. Note: Correlation only works if clocks agree. Configure NTP on every device and on your monitoring and log servers before anything else. A syslog message timestamped five minutes off is worse than useless during an incident review. ## SNMP: polling metrics and receiving traps The Simple Network Management Protocol lets a manager (your monitoring system) read values from an agent (the device). Each value is identified by an object identifier (OID) defined in a Management Information Base (MIB). For example, sysUpTime is 1.3.6.1.2.1.1.3.0 and the 64-bit inbound octet counter for an interface lives under ifHCInOctets, 1.3.6.1.2.1.31.1.1.1.6, from the IF-MIB defined in RFC 2863. SNMP works in two directions: - Polling: the manager sends Get, GetNext or GetBulk requests to the agent on UDP port 161 and receives responses. - Notifications: the agent sends traps (unacknowledged) or informs (acknowledged and retransmitted) to the manager on UDP port 162 when something happens, such as a link going down. ### SNMP versions Version | Security | Notes | SNMPv1 (RFC 1157) | Community string in clear text | 32-bit counters only; legacy, avoid | SNMPv2c (RFC 1901 and related) | Community string in clear text | Adds GetBulk, informs and 64-bit Counter64 | SNMPv3 (RFC 3411 to 3418) | User-based authentication and encryption | Use authPriv; the User-based Security Model is RFC 3414, AES privacy is RFC 3826 | SNMPv3 defines three security levels: noAuthNoPriv (username only), authNoPriv (authenticated, not encrypted) and authPriv (authenticated and encrypted). Use authPriv everywhere you can. Community strings in v1 and v2c are effectively passwords sent in plain text, and a read-write community is a remote configuration interface for anyone who captures it. ### Why 64-bit counters matter Interface counters are cumulative; your monitoring system calculates throughput from the difference between two polls. A 32-bit octet counter wraps after 4,294,967,296 bytes. At a sustained 1 Gbps that takes only about 34 seconds, and at 10 Gbps about 3.4 seconds. With a five-minute polling interval, a 32-bit counter can wrap undetected on any link averaging more than roughly 114 Mbps, giving you nonsense graphs. Always poll the high-capacity counters (ifHCInOctets, ifHCOutOctets) and use ifHighSpeed, which reports interface speed in Mbps, for utilization calculations: Utilization (%) = (delta octets × 8) ÷ (poll interval in seconds × interface speed in bits per second) × 100 For example, 3,000,000,000 octets transferred in a 300-second interval on a 1 Gbps interface is (3,000,000,000 × 8) ÷ (300 × 1,000,000,000) × 100 = 8% average utilization. Remember that a five-minute average hides short bursts; a link averaging 40% can still drop packets during microbursts. ## Configuring SNMPv3 on Cisco IOS The configuration below creates a read-only SNMPv3 group restricted by an access list, a user with SHA authentication and AES encryption, and trap delivery to the monitoring server. Replace the passphrases with long, unique values from your password manager. ``` ip access-list standard ACL-SNMP permit host 192.0.2.50 deny any log ! snmp-server view NMS-VIEW iso included snmp-server group NMS-RO v3 priv read NMS-VIEW access ACL-SNMP snmp-server user nmsuser NMS-RO v3 auth sha AUTH-PASSPHRASE priv aes 128 PRIV-PASSPHRASE ! snmp-server location HQ, Floor 2, IDF-2B, Rack 03 snmp-server contact noc@example.com snmp-server ifindex persist snmp-server trap-source Loopback0 snmp-server enable traps snmp linkdown linkup coldstart warmstart snmp-server enable traps config snmp-server enable traps envmon snmp-server host 192.0.2.50 version 3 priv nmsuser ``` A few details are worth knowing. The priv keyword on the group enforces authPriv, so a request without encryption is rejected. The access clause limits which source addresses can poll. SNMPv3 users are not displayed in show running-config; verify them with show snmp user and show snmp group, and remember that a configuration restored from backup will not recreate them. snmp-server ifindex persist keeps interface indexes stable across reloads so your graphs do not jump between interfaces. Where both your devices and monitoring platform support them, use stronger options such as AES-256 and SHA-2 family authentication. Finally, remove any legacy community strings with no snmp-server community. Test from the monitoring server with the Net-SNMP tools before adding the device to your platform: ``` snmpwalk -v3 -l authPriv -u nmsuser -a SHA -A 'AUTH-PASSPHRASE' \ -x AES -X 'PRIV-PASSPHRASE' 192.0.2.11 1.3.6.1.2.1.1 snmpget -v3 -l authPriv -u nmsuser -a SHA -A 'AUTH-PASSPHRASE' \ -x AES -X 'PRIV-PASSPHRASE' 192.0.2.11 1.3.6.1.2.1.31.1.1.1.6.1 ``` Pro tip: Use a consistent snmp-server location format that matches your documentation, such as site, floor, closet and rack. Monitoring platforms display it on every alert, so the on-call engineer knows exactly where a failed device lives. Our network documentation guide explains how to build that naming standard. ## Syslog: severity levels and central logging Syslog is the event log of your network. Every interface flap, configuration change, login, routing adjacency change and hardware warning produces a message. The modern message format is defined in RFC 5424, transport over UDP in RFC 5426 and transport over TLS in RFC 5425. By default devices send to UDP port 514; syslog over TLS uses TCP port 6514. ### Syslog severity levels 0 to 7 Every message carries a severity. Lower numbers are more severe, and when you configure a logging level on a device, it sends that level and everything more severe. Level | Severity (RFC 5424) | Cisco IOS keyword | Meaning and typical examples | 0 | Emergency | emergencies | System is unusable | 1 | Alert | alerts | Action must be taken immediately, such as a critical temperature condition | 2 | Critical | critical | Critical conditions, such as memory allocation failures or a port blocked by BPDU Guard | 3 | Error | errors | Error conditions, such as %LINK-3-UPDOWN when an interface goes down | 4 | Warning | warnings | Warning conditions, such as a port placed in err-disabled state or MAC address flapping | 5 | Notice | notifications | Normal but significant events, such as %SYS-5-CONFIG_I configuration changes and routing adjacency changes | 6 | Informational | informational | Informational messages, such as access list matches logged by the device | 7 | Debug | debugging | Debug output; never send to a remote server in production by default | Sending level 6 (informational) to your central log server is a sensible default: you capture configuration changes, adjacency changes and interface events without debug noise. Keep the console at a low verbosity so a flood of messages cannot make the console unusable during an incident. ### Syslog configuration on Cisco IOS ``` ntp server 192.0.2.123 service timestamps log datetime msec localtime show-timezone service sequence-numbers ! logging buffered 64000 informational logging console critical logging trap informational logging origin-id hostname logging source-interface Loopback0 logging host 192.0.2.60 ``` Millisecond timestamps with the time zone shown make correlation across devices possible, sequence numbers reveal lost messages, and a fixed source interface means the log server always sees the same address for each device. The local buffer gives you recent history even if the log server is unreachable. Because UDP syslog is unacknowledged and unencrypted, consider TLS transport for sensitive environments where both ends support it, and always restrict who can send to your collector. Watch out: A central log server is only useful if someone or something reads it. Configure your log platform to raise alerts on specific high-value messages, such as configuration changes outside change windows, repeated authentication failures, or BPDU Guard and err-disable events, rather than expecting humans to scroll through logs. ## NetFlow and IPFIX: who is using the network SNMP tells you a link is 95% utilized. Flow data tells you why. A flow is a set of packets sharing common properties, typically source and destination addresses, ports, protocol, type of service and input interface. The device keeps a cache of active flows and exports summary records, such as byte and packet counts and timestamps, to a collector. - NetFlow v5 has a fixed IPv4-only record format; it is still widely supported but inflexible. - NetFlow v9 (described in RFC 3954) introduced templates, so records can carry IPv6 and other fields. - IPFIX (RFC 7011) is the IETF standard derived from v9 and is the best choice where supported. - sFlow takes a different approach, exporting sampled packet headers plus interface counters, and is common on high-speed switches. Flow data answers questions like which hosts are the top talkers on the WAN, which applications consume the most bandwidth, whether a host is scanning the network, and what traffic crossed a boundary during a security incident. It is equally valuable for capacity planning and for proving whether a performance complaint is a network issue at all. ### Flexible NetFlow configuration on Cisco IOS-XE Flexible NetFlow separates the flow definition (record), the destination (exporter) and the cache settings (monitor), then applies the monitor to interfaces: ``` flow record FR-IPV4 match ipv4 tos match ipv4 protocol match ipv4 source address match ipv4 destination address match transport source-port match transport destination-port match interface input collect interface output collect counter bytes long collect counter packets long collect timestamp sys-uptime first collect timestamp sys-uptime last ! flow exporter FE-COLLECTOR destination 192.0.2.70 source Loopback0 transport udp 2055 export-protocol netflow-v9 template data timeout 60 ! flow monitor FM-IPV4 exporter FE-COLLECTOR record FR-IPV4 cache timeout active 60 cache timeout inactive 15 ! interface GigabitEthernet0/0/1 description WAN ip flow monitor FM-IPV4 input ip flow monitor FM-IPV4 output ``` Verify with show flow monitor FM-IPV4 cache and show flow exporter statistics. The active timeout of 60 seconds makes long-lived flows report regularly rather than only when they end, which keeps graphs accurate. Create a matching IPv6 record if you run dual-stack, as described in our IPv6 guide. On busy links or platforms with limited resources, use sampled flow export; you lose some precision but keep the trends. ## Ports and firewall rules for monitoring Monitoring traffic often crosses firewalls between the management network and devices in other zones. Allow only what is needed, only between the specific monitoring hosts and devices: Protocol | Transport and port | Direction | SNMP polling | UDP 161 | Monitoring server to device | SNMP traps and informs | UDP 162 | Device to monitoring server | Syslog | UDP 514 | Device to log server | Syslog over TLS | TCP 6514 | Device to log server | NetFlow v5/v9 | UDP, no assigned port (2055, 9995 or 9996 by convention) | Device to collector | IPFIX | UDP or TCP 4739 | Device to collector | sFlow | UDP 6343 | Device to collector | NTP | UDP 123 | Device to time server | ICMP echo | ICMP (no port) | Monitoring server to device | Our port lookup tool is handy when you need to check other services quickly. Treat the management plane as sensitive: restrict SNMP with access lists on the device as well as the firewall, as recommended in our firewall hardening checklist. ## Designing alerts that matter Collecting data is the easy part. The hard part is turning it into alerts that are rare enough to be taken seriously and reliable enough that nothing important is missed. An alert that fires every day and is always ignored trains your team to ignore alerts, including the one that matters. ### Principles for good alerts - Every alert must be actionable. If the response is "nothing, it will clear on its own," it should not be an alert. Put it on a dashboard instead. - Use duration and hysteresis. Alert when a WAN link exceeds 85% utilization for 15 minutes, not on a single sample, and clear only when it falls below a lower threshold such as 70%, so the alert does not flap. - Model dependencies. If a branch router is down, suppress alerts for every switch and access point behind it. One alert with the root cause beats forty symptoms. - Separate urgency levels. Pages are for issues that hurt users now. Tickets are for issues that need attention within a business day. Everything else is a report. - Link to a runbook. Every alert should tell the responder what it means and where the procedure is. - Respect maintenance windows. Planned reloads should not wake anyone up. - Review regularly. Once a month, look at which alerts fired most and which were ignored, then tune or delete them. ### A starter alert set Condition | Source | Suggested response | Core, WAN or firewall device unreachable | ICMP and SNMP polling | Page immediately | Internet or WAN circuit down | SNMP, trap or syslog | Page if no redundancy; urgent ticket if failover worked | Routing neighbor down | Syslog or trap | Page if it removes the only path; otherwise ticket | WAN utilization above 85% for 15 minutes | SNMP polling, then flow data | Ticket; investigate top talkers | Interface errors increasing steadily | SNMP polling | Ticket; check cabling, optics and duplex | Redundant power supply or fan failed | Trap or syslog | Next-business-day ticket | CPU above 90% for 10 minutes | SNMP polling | Ticket; check for loops, floods or process issues | Configuration change outside change window | Syslog | Notify the team channel for review | Repeated failed logins | Syslog | Security ticket | Certificate or license expiring within 30 days | Monitoring or inventory checks | Ticket | When an alert does fire, the data you have collected becomes your evidence: utilization graphs, the syslog sequence around the event and flow records for the affected link. Use it with a disciplined troubleshooting methodology instead of guessing. Pro tip: Monitor your monitoring. Set up a simple heartbeat check from outside the platform, so you are notified if the monitoring server itself stops polling or sending notifications. Silence from a broken monitoring system looks exactly like a healthy network. ## Building your monitoring stack step by step There are capable open-source and commercial monitoring platforms, and the right choice depends on your size, skills and budget. Whatever you choose, the rollout follows the same order: - Fix the foundations: NTP everywhere, consistent hostnames, a dedicated management network or VLAN, and loopback or management source interfaces. - Start with availability: ICMP and SNMPv3 polling of every infrastructure device, plus traps for link and hardware events. - Centralize logs: send syslog from every device at informational level, retain it for a period that satisfies your security and compliance needs, and alert on key messages. - Add performance and capacity: interface utilization, errors and discards on uplinks and WAN links, CPU and memory, with at least a few weeks of baseline before setting thresholds. - Add flow data on internet and WAN edges first, then expand to data center or core links as needed. - Tune alerts continuously and automate device onboarding so new equipment is monitored from day one; the techniques in our network automation guide help here. A baseline is the most underrated part of this process. Knowing that a link normally peaks at 40% on Monday mornings is what makes 80% meaningful, and it is the only defensible basis for a capacity upgrade request. ## Key takeaways - SNMP, syslog and flow data answer different questions; a complete monitoring setup uses all three, correlated by accurate NTP time. - Use SNMPv3 with authPriv, restrict it with access lists, and always poll 64-bit interface counters. - Know the ports: SNMP UDP 161 and 162, syslog UDP 514 or TCP 6514 for TLS, IPFIX 4739, and conventional NetFlow ports such as 2055. - Syslog severities run from 0 (emergency) to 7 (debug); send informational (6) to a central server and alert on key messages. - Flow data explains what traffic is on a link, which turns "the network is slow" into a specific, solvable problem. - Make every alert actionable, use durations and dependencies, separate pages from tickets, and review alert noise regularly. Not sure whether your monitoring would catch the next outage before your users do? Our Network Health Assessment reviews your visibility, configuration and alerting and gives you a prioritized improvement plan. For anything else, get in touch. ## FAQ Q: Which ports do SNMP, syslog and NetFlow use? A: SNMP agents listen on UDP 161 for polling, and managers receive traps and informs on UDP 162. Syslog uses UDP 514 by default, and syslog over TLS uses TCP 6514. NetFlow has no IANA-assigned port, though UDP 2055, 9995 and 9996 are common conventions; IPFIX uses port 4739. Q: Should I still use SNMPv2c? A: Only where a device supports nothing better, and then only with read-only access, a long random community string and an access list limiting which hosts can query it. SNMPv2c sends the community string in clear text. SNMPv3 with authPriv provides authentication and encryption and should be your default. Q: How often should I poll network devices with SNMP? A: Five minutes is a common default for interface statistics and health metrics, and one minute is reasonable for critical links and core devices if your monitoring system and devices can handle the load. Always use 64-bit counters for interfaces faster than about 100 Mbps so counters do not wrap between polls. Q: What is the difference between SNMP traps and syslog? A: Both are event notifications pushed by the device. Traps are structured SNMP messages defined in MIBs and are easy for monitoring systems to parse, while syslog messages are human-readable text with a facility and severity. Most networks use both, with traps feeding the monitoring platform and syslog feeding a central log server. Q: How do I reduce alert fatigue? A: Alert only on conditions that require human action, use durations and hysteresis so brief spikes do not fire alerts, model dependencies so one failed uplink does not generate dozens of downstream alerts, route low-urgency issues to tickets instead of pages, and review noisy alerts regularly. --- # Structured Cabling and Fiber Basics Every Network Admin Should Know URL: https://roadtoneteng.com/structured-cabling-and-fiber-basics/ Updated: 2026-10-14 Switches get replaced every five to eight years. Access points even sooner. The cabling behind them often stays in the walls for fifteen to twenty-five years, which makes it the longest-lived and least forgiving part of your network. Poorly installed or undocumented cabling causes intermittent errors that waste hours of troubleshooting, limits the speeds you can upgrade to, and turns every move or change into guesswork. This guide covers the structured cabling and fiber knowledge every network admin should have: TIA-568 essentials, copper categories, multimode and single-mode fiber, connectors, patch panel labeling and how cabling is tested. ## Why the physical layer deserves your attention Most network admins learn a lot about protocols and very little about cabling, until a link starts throwing CRC errors or a new access point refuses to negotiate above 1 Gbps. Layer 1 problems are some of the hardest to diagnose because the symptoms are indirect: slow file transfers, VoIP call quality issues, Wi-Fi complaints or links that flap only when the air conditioning cycles. That is why a good troubleshooting methodology starts at the physical layer. Understanding cabling also makes you a better buyer. You do not need to terminate cables yourself, but you do need to specify the right category, review a cabling contractor's proposal, check test reports and recognize a sloppy installation before you sign off on it. Those decisions shape what your network can do for the next two decades. Note: This article focuses on North American TIA standards because they are widely referenced. The international equivalent is ISO/IEC 11801, and Europe uses the EN 50173 series. The concepts, and most of the numbers, line up closely. ## Structured cabling and the TIA-568 family Structured cabling means a standardized, hierarchical cabling system that is independent of the equipment plugged into it. Instead of running cables directly from a switch to a desk, you install permanent cabling between patch panels and outlets, then make connections with short patch cords. Moves and changes become patching jobs rather than construction projects. ### The standards that matter - ANSI/TIA-568 is the core series: TIA-568.0 covers generic customer-premises cabling, TIA-568.1 commercial buildings, TIA-568.2 balanced twisted-pair cabling and components, and TIA-568.3 optical fiber cabling and components. - ANSI/TIA-569 covers pathways and spaces: conduits, trays and telecommunications room design. - ANSI/TIA-606 covers administration, meaning labeling and records. - ANSI/TIA-607 covers bonding and grounding. - ANSI/TIA-942 addresses data center infrastructure. ### The building blocks of a structured system - Entrance facility: where service provider and campus cables enter the building. - Equipment room: the main room for core switches, servers and the building's main cross-connect. - Telecommunications room (TR): the wiring closet on each floor or zone that serves the horizontal cabling, often called an IDF. - Backbone cabling: links between the equipment room and TRs, and between buildings, usually fiber. - Horizontal cabling: runs from a TR patch panel to work-area outlets, ceiling-mounted access points and other endpoints, usually twisted-pair copper in a star topology. - Work area: the outlet and the patch cord to the device. ### The 90 plus 10 rule A twisted-pair channel is limited to 100 meters. That budget is split into a permanent link of up to 90 meters of solid-conductor horizontal cable, from the patch panel to the outlet, plus up to 10 meters total of patch cords at both ends. Stranded patch cords have higher attenuation than solid cable, which is why the split exists. Plan TR locations so that no outlet is more than 90 meters of cable path away, remembering that cable routes up, across and down rather than in a straight line. ## Copper categories: Cat5e, Cat6, Cat6A and beyond Twisted-pair cable categories define performance up to a specified frequency, which in turn determines which Ethernet speeds a link supports over which distances. Category | Specified bandwidth | Ethernet support | Typical use today | Cat5e | 100 MHz | 1000BASE-T and 2.5GBASE-T to 100 m; 5GBASE-T may work but is not guaranteed | Existing installations; not recommended for new builds | Cat6 | 250 MHz | Up to 5GBASE-T to 100 m; 10GBASE-T to about 55 m depending on alien crosstalk | Desktop connections where 1 Gbps is enough | Cat6A | 500 MHz | 10GBASE-T to 100 m | New installations, access points, high-power PoE | Cat8 | 2000 MHz | 25GBASE-T and 40GBASE-T to 30 m | Short data center links between adjacent racks | Category 7 and 7A are ISO/IEC classes (F and FA) and are not recognized by TIA; you will rarely see them specified in North America. For new horizontal cabling, Cat6A is the sensible default. Wi-Fi 6, 6E and 7 access points increasingly use multigigabit uplinks at 2.5, 5 or 10 Gbps, and industry guidance for access point cabling recommends Cat6A. If you are planning wireless, see our enterprise Wi-Fi design guide for how cabling fits into AP placement. ### Practical details that affect performance - Solid versus stranded: use solid-conductor cable for permanent links and stranded cable only for patch cords. - Unshielded versus shielded: U/UTP is standard and easy to install. Shielded cable such as F/UTP or S/FTP improves noise immunity and alien crosstalk performance but must be properly bonded end to end, or the shield can make matters worse. - Avoid copper-clad aluminum (CCA): it does not meet TIA-568 requirements, has higher resistance, runs hotter with PoE and breaks more easily. - Jacket ratings: building and fire codes dictate where each rating may be used. In North America, CMP (plenum) is required in air-handling spaces, CMR (riser) for vertical runs between floors, and CM for general use. Many regions specify low-smoke zero-halogen (LSZH) jackets instead. - Installation workmanship: keep pair untwisting at terminations to no more than 13 mm (0.5 inch), respect a minimum bend radius of four times the cable diameter for four-pair horizontal cable, and do not exceed 110 N (25 lbf) of pulling tension. Over-tightened cable ties that deform the jacket degrade performance too; hook-and-loop straps are kinder. ## T568A and T568B wiring TIA-568 defines two pin assignments for eight-position modular jacks. Both perform identically; what matters is using the same one at both ends of every permanent link and across the whole installation. Many projects specify T568A, while T568B is very common in commercial installations in North America. Pin | T568A | T568B | 1 | White/green | White/orange | 2 | Green | Orange | 3 | White/orange | White/green | 4 | Blue | Blue | 5 | White/blue | White/blue | 6 | Orange | Green | 7 | White/brown | White/brown | 8 | Brown | Brown | A cable wired T568A on one end and T568B on the other is a crossover cable. With Auto-MDI/MDI-X supported on practically all modern switch ports, and required for 1000BASE-T and faster to use all four pairs regardless, crossover cables are largely obsolete. Mixing standards in permanent cabling, however, still causes confusion and failed tests, so specify one and enforce it. ## Power over Ethernet and cable choice Power over Ethernet turns your data cabling into a power distribution system for phones, access points, cameras, lighting and building sensors. Higher power means more current, and more current means more heat in the cable bundle. Standard | Type | Power at switch port (PSE) | Power available at device (PD) | Pairs used | IEEE 802.3af (PoE) | Type 1 | 15.4 W | 12.95 W | 2 | IEEE 802.3at (PoE+) | Type 2 | 30 W | 25.5 W | 2 | IEEE 802.3bt | Type 3 | 60 W | 51 W | 4 | IEEE 802.3bt | Type 4 | 90 W | 71.3 W | 4 | The difference between PSE and PD power is lost as heat in the cable over a full-length channel. In large bundles that heat accumulates, raising conductor temperature and insertion loss. TIA TSB-184-A provides guidance on bundle sizes and cable choice for power delivery; in practice, Cat6A with its larger conductors handles heat better, and smaller bundles in open pathways help. If you plan to deploy high-power PoE devices, tell your cabling designer up front. ## Fiber basics: multimode and single-mode Fiber carries light instead of electrical signals, which means no electromagnetic interference, no ground loops between buildings and far greater distances. Every fiber has a core that carries light and a cladding, typically 125 microns in diameter, that keeps it there. The core size defines the fiber type. - Multimode fiber (MMF) has a 50 or 62.5 micron core. Light travels in many paths (modes), which limits distance, but inexpensive 850 nm VCSEL optics make it the cost-effective choice inside buildings and data centers. - Single-mode fiber (SMF) has a core of about 9 microns. Light travels essentially in one mode, allowing distances of kilometers using 1310 nm and 1550 nm lasers. Single-mode optics used to be much more expensive, but the gap has narrowed considerably, and SMF is increasingly chosen for backbones to future-proof them. Type | Core/cladding | Typical jacket color | 10GBASE-SR reach | 40GBASE-SR4 / 100GBASE-SR4 reach | Notes | OM1 | 62.5/125 µm | Orange | 33 m | Not supported | Legacy; avoid for new work | OM2 | 50/125 µm | Orange | 82 m | Not supported | Legacy | OM3 | 50/125 µm laser-optimized | Aqua | 300 m | 100 m / 70 m | Common in existing buildings | OM4 | 50/125 µm laser-optimized | Aqua or violet | 400 m | 150 m / 100 m | Preferred multimode for new work | OM5 | 50/125 µm wideband | Lime green | 400 m | 150 m / 100 m | Adds short-wavelength WDM (about 850 to 950 nm) | OS2 | 9/125 µm single-mode | Yellow | Not applicable (uses LR optics: 10 km) | Uses LR4 optics: 10 km | Backbones, campus and long runs | Watch out: Never mix fiber types in the same link. Patching a 62.5-micron OM1 cord into a 50-micron OM3 link, or multimode into single-mode, causes massive loss. Jacket colors help, but always check the printed legend on the cable before patching. ## Fiber connectors, polish and polarity ### Common connector types - LC: a small form-factor connector with a 1.25 mm ferrule and latch, usually in duplex pairs. It is the standard interface on SFP, SFP+, SFP28 and most duplex QSFP optics, and the dominant connector in modern patch panels. - SC: a larger push-pull connector with a 2.5 mm ferrule. It is common in older enterprise installations and widely used in service provider and fiber-to-the-premises networks. - ST: a legacy bayonet-style connector found in older multimode installations. - MPO/MTP: multi-fiber connectors with 8, 12, 16 or 24 fibers in one ferrule, used for high-density trunks and parallel optics such as 40GBASE-SR4 and 100GBASE-SR4, which use eight fibers. MTP is a branded variant of MPO. ### UPC versus APC Connectors also differ in end-face polish. UPC (ultra physical contact) connectors have a slightly domed, flat end face; single-mode UPC connectors are usually blue. APC (angled physical contact) connectors are polished at an 8-degree angle to reduce back reflection and are green. APC is common in passive optical networks and RF-over-fiber; most enterprise Ethernet optics use UPC. Never mate APC with UPC. ### Polarity Duplex fiber links need the transmitter at one end connected to the receiver at the other. TIA-568 defines polarity methods so that this works consistently through patch panels and trunks; for duplex links the principle is A-to-B, meaning position A at one end connects to position B at the other. For MPO trunk systems, the chosen method (A, B or C) determines which trunk, cassette and patch cord types you need, so stay consistent across the installation. When a new fiber link shows no light at all, reversed polarity is one of the first things to check. ## Patch panels, labeling and cable management A cabling system that cannot be identified cannot be managed. TIA-606 defines an administration standard with classes that scale from a single telecommunications room to multi-building campuses, and a consistent identifier scheme for spaces, racks, panels, ports and cables. ### A practical labeling scheme Whatever format you adopt, an identifier should tell you where the other end is. A simple scheme in the spirit of TIA-606 encodes floor, room, rack, panel and port: Label | Meaning | 2B-R03-PA-24 | Floor 2, telecom room B, rack 03, patch panel A, port 24 | Outlet faceplate: 2B-R03-PA-24 | The same identifier at the work area, so the two ends always match | 1A-R01-FA-05/06 | Floor 1, equipment room A, rack 01, fiber panel A, ports 5 and 6 (a duplex pair) | - Label both ends of every permanent link and every backbone cable, plus the panel and the faceplate. - Use printed, durable labels; handwriting fades and smudges. - Record every link in your documentation with its test result, and keep the identifiers identical to the physical labels. Our network documentation guide covers how to keep those records current. - Match switch interface descriptions to the patch panel port, for example description 2B-R03-PA-24 Room 214 desk 3, so show interfaces description tells you where a port goes. ### Rack and patching discipline Use horizontal cable managers between panels and switches, choose patch cord lengths that fit rather than coiling excess, and adopt a simple color convention, for example one color for access ports, another for uplinks and another for management. Keep power and data separated where possible. A tidy rack is not about appearance; it is about being able to trace and replace a cable in minutes without disturbing neighboring connections. ## Testing, certification and troubleshooting ### Copper testing levels - Verifiers check continuity and wire map: opens, shorts, reversed and split pairs. Useful, but they say nothing about performance. - Qualifiers determine whether a link can support a particular Ethernet speed, which is handy for troubleshooting existing cabling. - Certifiers measure the link against TIA or ISO category limits: wire map, length, insertion loss, near-end crosstalk (NEXT) and power sum NEXT, far-end crosstalk (ACR-F), return loss, propagation delay and delay skew, and resistance unbalance relevant to PoE. Certification reports are normally required for manufacturer warranties. New links are usually tested as a permanent link, panel to outlet, excluding patch cords. Insist on a certification report for every link in a new installation, check that each result says PASS rather than a marginal result, and store the reports with your documentation. ### Fiber testing Tier 1 testing uses an optical loss test set, a calibrated light source and power meter, to measure insertion loss, length and polarity. Tier 2 testing adds an OTDR trace that shows the location and loss of each connector, splice and fault along the link. Before any testing or connection, inspect and clean every end face: contamination is the leading cause of fiber link problems, and a single dust particle on a single-mode core can cause significant loss. ### Calculating a loss budget Compare measured loss with a calculated maximum using TIA-568.3 allowances: 3.5 dB per kilometer for multimode at 850 nm, 1.0 dB per kilometer for inside-plant single-mode (0.5 dB per kilometer outside plant), 0.75 dB per mated connector pair and 0.3 dB per splice. For a 120-meter OM4 link with a connector pair at each patch panel and no splices: Fiber: 0.12 km × 3.5 dB/km = 0.42 dB. Connectors: 2 × 0.75 dB = 1.50 dB. Maximum allowable loss: 1.92 dB. A well-installed link will measure well under that maximum. Also confirm the total is within the loss budget of the optics you plan to use, which the transceiver data sheet or the relevant IEEE standard specifies. ### Checking cabling from the switch Your switches can tell you a lot about the physical layer. Rising CRC and input errors usually point to cabling, connectors or duplex issues; optical power readings reveal dirty or failing fiber links; and many Catalyst switches include a time-domain reflectometer test for copper: ``` show interfaces GigabitEthernet1/0/24 show interfaces GigabitEthernet1/0/24 counters errors show interfaces transceiver detail test cable-diagnostics tdr interface GigabitEthernet1/0/24 show cable-diagnostics tdr interface GigabitEthernet1/0/24 ``` Watch interface error counters over time rather than as a one-off snapshot; a monitoring platform that trends errors per interface, as described in network monitoring 101, catches a degrading cable long before users notice. Watch out: Never look into a fiber connector or optic, even if you believe it is dark. Infrared light used by network optics is invisible and can damage your eyes. Use an inspection scope with a screen and a power meter to confirm whether a fiber is live. Pro tip: Keep a fiber cleaning kit, a spare set of known-good patch cords and a basic copper verifier in every telecommunications room. Swapping a patch cord resolves a surprising number of "network problems" in seconds. ## Key takeaways - Cabling outlives every active device, so specify it carefully: Cat6A for new horizontal copper, OM4 or OS2 for backbones. - Respect the 100-meter channel: up to 90 meters of permanent link plus up to 10 meters of patch cords. - Pick T568A or T568B and use it consistently; avoid CCA cable and use the correct jacket rating for each space. - Plan for PoE heat with appropriate cable and bundle sizes, especially for 802.3bt devices. - Match fiber types and polish: never mix multimode core sizes, multimode with single-mode, or APC with UPC. - Label both ends of every link, keep records that match the labels, and demand certification reports for every new installation. - Inspect and clean fiber before every connection, and trend interface errors to catch physical problems early. Planning an office move, a new build or a cabling refresh? Our Small Business Network Setup service covers cabling requirements, contractor coordination and acceptance testing alongside the network itself. If you would like a second opinion on a cabling proposal, contact us. ## FAQ Q: Should I install Cat6 or Cat6A for a new office? A: For new installations, Cat6A is the safer choice. It supports 10GBASE-T over the full 100-meter channel, handles high-power PoE better because of its larger conductors and improved heat dissipation, and is recommended for wireless access point cabling. Cat6 is adequate for 1 Gbps desktops but limits 10GBASE-T to about 55 meters. Q: What is the maximum length of an Ethernet cable run? A: Under TIA-568, a twisted-pair channel is limited to 100 meters: up to 90 meters of solid-conductor permanent link from patch panel to wall outlet, plus up to 10 meters total of patch cords at both ends. Exceeding it may appear to work at low speeds but causes errors and is not standards-compliant. Q: What is the difference between OM3, OM4 and OS2 fiber? A: OM3 and OM4 are 50-micron laser-optimized multimode fibers, usually with aqua jackets, used with low-cost 850 nm optics over short distances; OM4 has higher bandwidth and longer reach, for example 400 meters for 10GBASE-SR versus 300 meters on OM3. OS2 is 9-micron single-mode fiber, typically yellow, used with 1310 or 1550 nm optics for distances of kilometers. Q: Can I connect an APC connector to a UPC connector? A: No. APC connectors have an 8-degree angled end face and are usually green; UPC connectors have a flat, domed end face and are usually blue on single-mode. Mating them leaves an air gap that causes high loss and can damage both end faces. Always match polish types. Q: Do I need certification testing or is a simple cable tester enough? A: A simple continuity tester only checks wiring order. Certification testing measures performance parameters such as insertion loss, crosstalk and return loss against the category limits, and is required for most manufacturer warranties. For new installations, always ask the installer for certification reports for every link. --- # Service: Network Health Assessment URL: https://roadtoneteng.com/product/network-health-assessment/ Price: from $490 USD The Network Health Assessment is a structured, remote review of your business network. It answers three practical questions: what is working, what is at risk, and what should you fix first? You receive a plain-language report with prioritized recommendations, so you can make confident decisions about your network instead of guessing. ## Overview Many small business networks grow one device at a time. A router from the internet provider, a switch added when the office expanded, a few access points bought in a hurry, a firewall rule created years ago for a reason nobody remembers. Each piece works, more or less, but nobody has looked at the whole picture. Problems such as slow Wi-Fi, intermittent drops, outdated firmware or overly permissive firewall rules stay hidden until they cause an outage or a security incident. This assessment gives you that whole picture. Using the same methodical approach we teach in our guides, we review your devices, configurations, topology and security posture, then translate our findings into a short, prioritized action plan. It is the best first step if you are not sure where your network stands or what to invest in next. ## Who it is for - Small and mid-sized businesses without a dedicated network engineer. - Offices experiencing slow performance, unreliable Wi-Fi or unexplained outages. - IT generalists who want an independent second opinion on the network they manage. - Owners and managers preparing to grow, move offices or replace equipment and want to know what is worth keeping. - Organizations that have recently taken over a network from a previous provider and inherited little or no documentation. ## What is included The standard scope covers a single site with up to 25 network devices, including routers, firewalls, switches and wireless access points or controllers. Within that scope we review: - Topology and design: how devices connect, how traffic flows, where single points of failure exist and whether the layout suits your size and needs. - Configuration quality: IP addressing, VLANs, routing, DHCP and DNS settings, spanning tree, and consistency across devices. - Security posture: management access, default or weak credentials, exposed services, firewall rule hygiene, guest network isolation and logging. This draws on our firewall hardening checklist. - Performance and reliability: interface errors, utilization, duplex mismatches, wireless channel planning and signal concerns reported by users. - Lifecycle status: firmware versions, end-of-support hardware and devices that no longer receive security updates. - Backups and documentation: whether configurations are backed up and whether any existing documentation matches reality. ### Deliverables - A written assessment report (PDF and editable document) with an executive summary for non-technical readers. - A findings table rating each issue by severity, effort and impact. - A prioritized action plan split into quick wins, short-term improvements and longer-term projects. - A high-level topology diagram of the network as found. - A 60-minute walkthrough call to explain results and answer questions. - 14 days of email follow-up for clarifying questions after delivery. ## Process and timeline Most assessments are completed within 5 to 7 business days once we have the information and access we need. - Intake (day 0): after checkout, you complete a short questionnaire about your site, devices, users and known problems. - Kickoff call (day 1): a 30-minute call to confirm goals, agree on access and schedule any live sessions. - Data collection (days 1–3): we gather configurations and status information using read-only access, supervised screen sharing or exports you provide. - Analysis (days 3–5): we review configurations, compare them against good practice and identify risks and improvements. - Reporting (days 5–7): we deliver the written report and hold the walkthrough call. ## What we need from you - A main contact who can answer questions and coordinate access. - Read-only or temporary administrative access to in-scope devices, or configuration exports if you prefer. - Someone available during agreed sessions to share their screen or run simple commands if remote access is not possible. - Any existing documentation, diagrams or notes from previous providers, however incomplete. - A short list of known problems or concerns from staff, if available. Please do not send passwords by plain email. We will agree a secure method for sharing access during the kickoff call, and we recommend rotating any shared credentials once the assessment is complete. ## What is not included - Implementing fixes or making configuration changes. The assessment is analysis only. - Servers, endpoints, cloud applications, email systems or phone systems beyond their network connectivity. - Penetration testing, vulnerability scanning with intrusive tools or formal compliance audits. - On-site visits, physical cabling surveys or professional wireless site surveys with specialized equipment. - Networks larger than the standard scope or with multiple sites, unless agreed in writing in advance. - Purchasing or reselling hardware. ## The outcome At the end of the assessment you will understand your network clearly, know which risks matter most and have a realistic plan to address them in order. You can use the report to budget for improvements, brief their management, or give a new IT provider a head start. If you want help acting on the findings, the Firewall & Security Hardening and Network Documentation & Diagram Package services are natural next steps. Have questions before ordering? Read our FAQ or contact us. --- # Service: Small Business Network Setup URL: https://roadtoneteng.com/product/small-business-network-setup/ Price: from $1250 USD The Small Business Network Setup service gives you a network that is designed properly from day one: segmented, secure, reliable and fully documented. Whether you are opening a new office, moving premises or rebuilding a network that grew without a plan, we design, configure and validate it with you, then hand over everything you need to run it with confidence. ## Overview A small business network does not need to be complicated, but it does need to be deliberate. Too many offices run everything on a single flat network where staff laptops, guest phones, printers, cameras and payment terminals all share the same space. That makes troubleshooting harder and turns a single compromised device into a risk for everything else. In this engagement we start with your actual requirements, design a sensible structure with separate networks for different kinds of devices, and configure your firewall, switches and wireless system to match. Every decision is explained in plain language and recorded in documentation that you own. The design follows the same principles covered in our guides on VLANs, Wi-Fi design and firewall hardening. ## Who it is for - Businesses opening a new office, shop, clinic or studio. - Organizations moving to new premises and wanting a clean start. - Teams whose existing network has become unreliable, insecure or impossible to understand. - Businesses replacing consumer-grade equipment with business-grade gear. - IT generalists who want an expert to design and build the foundation they will maintain. ## What is included The standard scope covers a single site with one firewall or router, up to four switches, up to eight wireless access points and up to 50 users. - Requirements workshop: a structured call to understand your users, devices, applications, internet service, growth plans and any security or compliance concerns. - Network design: logical topology, VLAN plan (for example staff, guest, voice, printers and cameras or IoT), IP addressing using a clear subnetting scheme, DHCP and DNS design, and inter-VLAN firewall policy. - Equipment guidance: a vendor-neutral bill of materials, or an assessment of whether your existing equipment is suitable. - Firewall configuration: secure management access, inter-VLAN rules based on least privilege, guest isolation, sensible outbound policy, logging and firmware updates. - Switch configuration: VLANs, trunk and access ports, port security basics, spanning tree, management network and descriptive port labeling. - Wireless configuration: separate staff and guest SSIDs, WPA2 or WPA3 security, channel and power planning, and band settings. - Testing and validation: connectivity, segmentation, failover where applicable, Wi-Fi coverage checks with your on-site contact, and configuration backups. ### Deliverables - A design document explaining the network structure and the reasoning behind it. - Logical and physical network diagrams. - An IP addressing and VLAN plan. - Device inventory and port map. - Backed-up configuration files for every in-scope device. - A short operations guide covering common tasks such as adding a user device or changing the guest Wi-Fi password. - A 90-minute handover call and 30 days of email support for questions about the delivered setup. ## Process and timeline A typical engagement takes 2 to 3 weeks, depending mainly on equipment delivery and on-site availability. - Week 1, discovery and design: intake questionnaire, requirements workshop, design proposal and bill of materials. We confirm the design with you in writing before configuration begins. - Week 1–2, preparation: once equipment is available, devices are connected for remote management and baseline configurations are applied. - Week 2, configuration: full firewall, switch and wireless configuration, carried out in agreed change windows with rollback options. - Week 2–3, testing and cutover: validation, user testing and cutover from any old network, scheduled to minimize disruption. - Week 3, handover: documentation delivered and handover call completed. On-site assistance is optional and available only by separate written agreement covering location, travel and any additional costs. For most setups, a trusted person on site following our instructions is enough. ## What we need from you - A main contact with authority to approve the design and schedule changes. - Business-grade equipment, either existing or purchased according to the agreed bill of materials. - Working internet service and the account details from your provider. - Someone on site to unpack, mount and connect devices and to help test coverage, unless on-site work is agreed. - Access to any existing network equipment that will be replaced or integrated. - Agreement on maintenance windows for cutover. ## What is not included - Hardware, software licenses or subscriptions, which you purchase directly. - Structured cabling, electrical work or rack installation. Our guide to structured cabling explains what to ask a local installer. - Configuration of servers, workstations, printers, phones, cameras or business applications beyond their network connectivity. - Multi-site connectivity, site-to-site VPNs between several locations or advanced routing, unless agreed in writing. - Ongoing managed services or monitoring after the support period. - Professional predictive or on-site wireless surveys with specialized equipment. ## The outcome You finish with a network that is segmented, secured, tested and documented, plus a clear understanding of how it works. Your team or any future IT provider can support it without reverse-engineering decisions, and you have a solid foundation for growth. To keep it healthy over time, consider a periodic Network Health Assessment. Questions about scope or equipment? Contact us before ordering and we will help you decide. --- # Service: Firewall & Security Hardening URL: https://roadtoneteng.com/product/firewall-security-hardening/ Price: from $690 USD Your firewall is the front door of your network, and in many small businesses it has not been reviewed since the day it was installed. The Firewall & Security Hardening service is a focused, remote engagement that reviews your firewall and network edge, removes unnecessary risk, and leaves you with a cleaner, safer and fully documented configuration. ## Overview Firewall configurations tend to accumulate history. A port forward opened for a contractor years ago, an "allow any" rule added during troubleshooting, a remote access VPN with shared accounts, management pages reachable from the internet, firmware that is several versions behind. None of these may be causing visible problems today, but together they make your network an easier target. This service applies a structured, checklist-driven approach, based on the principles in our free firewall hardening checklist, to your actual environment. We review what exists, agree on changes with you, implement them carefully with rollback options, and document everything. The goal is not perfection on paper but meaningful, practical risk reduction that your team can maintain. ## Who it is for - Small and mid-sized businesses with an existing firewall that has not been reviewed recently. - Organizations that have taken over a network from a previous IT provider. - Teams that recently experienced a security scare and want to close obvious gaps. - Businesses preparing for a cyber insurance questionnaire or a customer security review and wanting their edge in good shape. - IT generalists who want an expert to work through the firewall alongside them. ## What is included The standard scope covers one firewall or a single high-availability pair at one site, including its remote access VPN. - Rule base review: identification of unused, shadowed, duplicate or overly permissive rules, and a cleaned-up rule set based on least privilege. - NAT and exposed services: review of port forwards and published services, with recommendations to close, restrict or move them behind a VPN. - Management plane hardening: disabling management access from untrusted networks, enforcing strong authentication, removing default and shared accounts, and enabling multi-factor authentication where supported. - Remote access VPN review: authentication methods, individual user accounts, encryption settings and access restrictions. - Segmentation checks: verification that guest, staff and device networks are properly isolated, with inter-network rules tightened where needed. - Security services: review and tuning of available features such as intrusion prevention, DNS filtering or geo-restrictions, where your platform and licensing support them. - Logging and alerting: sensible log retention, time synchronization and alerts for important events. Our guide to network monitoring covers the wider picture. - Firmware and backups: firmware update planning and an automated or documented configuration backup routine. ### Deliverables - A findings report rating each issue by risk and describing the recommended fix. - A detailed change log listing every change made, when and why. - Before-and-after configuration backups. - A summary of the final rule base in readable form. - A list of remaining recommendations that were out of scope or deferred by you. - A 60-minute review call and 14 days of email follow-up. ## Process and timeline Most engagements are completed within 1 to 2 weeks. - Intake and kickoff: you complete a questionnaire covering your firewall model, services that must remain available and any known concerns. We agree secure access on a short kickoff call. - Review (days 1–3): we export and analyze the current configuration and document findings. - Change plan (days 3–4): we present proposed changes, explain their impact and agree which to implement and when. - Implementation (days 4–8): changes are applied in agreed maintenance windows, with a configuration backup before each stage and testing after. - Report and review (days 8–10): final documentation is delivered and we walk through the results together. Hardening can affect legacy systems or undocumented workflows that rely on open access. We identify these risks during the change plan, but please tell us about any critical services, remote users or third-party vendors that connect to your network. ## What we need from you - Administrative access to the firewall, provided through a temporary account or supervised session. - A list of business-critical services, remote users and third parties that need access. - A decision-maker who can approve changes and maintenance windows. - Access to any required vendor portals or licenses for firmware and security subscriptions. - Someone available during change windows to confirm that key services work. ## What is not included - Penetration testing, red teaming or formal vulnerability assessments. - Compliance certification or audit sign-off for any specific standard. - Endpoint security, email security, server hardening or cloud account configuration. - Purchase of firewall hardware, licenses or security subscriptions. - Multiple firewalls across several sites, unless agreed in writing. - Incident response for an active compromise. If you suspect an ongoing breach, contact a specialist incident response provider first. ## The outcome You end with a firewall that exposes only what it must, is managed securely, logs what matters and is documented clearly. You will also understand why each rule exists, which makes future changes safer. For a broader view of the whole network, pair this service with a Network Health Assessment, or keep everything recorded with our Network Documentation & Diagram Package. Unsure whether your firewall is in scope? Contact us with the make and model before you order. --- # Service: 1:1 CCNA Mentorship Program (8 Weeks) URL: https://roadtoneteng.com/product/ccna-mentorship-program/ Price: from $399 USD Preparing for the CCNA alone can feel like trying to drink from a fire hose. The 1:1 CCNA Mentorship Program gives you eight weeks of structure, accountability and hands-on guidance from someone who has walked the road from network administrator to network engineer. The focus is not just on passing an exam, but on understanding networks well enough to work on them with confidence. ## Overview The CCNA covers a wide range of topics: network fundamentals, switching, routing, IP services, security basics, wireless and an introduction to automation. Many learners struggle not because the material is impossible, but because they lack a plan, study passively, or never build enough lab practice to make concepts stick. This program addresses those problems directly. We begin by assessing where you are, then build a realistic eight-week plan around your schedule and the exam blueprint. Each week includes a live one-to-one session, a hands-on lab assignment and feedback on your work. The approach builds on the same principles in our free CCNA study plan and learning roadmap, adapted to you personally. ## Who it is for - Help desk technicians and system administrators moving into networking. - Network administrators who want to formalize their knowledge and fill gaps. - Self-studying learners who have started the CCNA but lost momentum. - Career changers with a grasp of basic IT concepts who want guided, practical study. - Students who want to supplement classroom learning with real lab practice. You will get the most from the program if you are already comfortable with basic IP addressing and know what a switch and router do. If not, start with Subnetting Made Simple and our learning roadmap first. ## What is included - Skills assessment: a short questionnaire and practical exercise before the first session to identify your strengths and gaps. - Personal study plan: an eight-week plan mapped to the exam topics, weighted toward the areas where you need the most help. - Eight live sessions: one 60-minute one-to-one video session each week for concept explanations, whiteboarding, live lab walkthroughs and review. - Weekly lab assignments: practical tasks such as building VLANs and trunks, configuring OSPF, setting up ACLs and NAT, and troubleshooting deliberately broken topologies. - Feedback on your work: written comments on submitted lab configurations and troubleshooting notes. - Subnetting and troubleshooting drills: regular short exercises to build speed and a methodical troubleshooting habit. - Written Q&A support: send questions by email between sessions during the program, with replies typically within two business days. - Exam readiness review: in the final weeks, a review of your progress and a practical plan for exam day or for continued study. ## Process and timeline The program runs for eight consecutive weeks from your first session. A typical structure looks like this, adjusted to your needs: - Week 1: assessment review, goal setting, lab environment check and network fundamentals. - Weeks 2–3: switching, VLANs, trunking, spanning tree and EtherChannel. - Weeks 4–5: IPv4 and IPv6 routing, static routes and OSPF. - Week 6: IP services such as DHCP, DNS, NAT, NTP and SNMP, plus security fundamentals and ACLs. - Week 7: wireless concepts and an introduction to automation and programmability. - Week 8: mixed troubleshooting labs, weak-area review and readiness planning. Sessions are scheduled at mutually agreed times. Please give at least 24 hours' notice to reschedule. ## What we need from you - A computer capable of running network simulation or emulation software, a stable internet connection, a microphone and ideally a webcam. - Six to ten hours per week for independent study and lab work in addition to the live session. - Your own study materials, such as a CCNA book or video course. We can recommend options during the first session. - Willingness to submit lab work and be honest about what you find difficult. ## What is not included - Exam vouchers, official courseware, books, practice exams or software licenses. - Any guarantee of passing the exam or of employment. - Unlimited on-demand support outside scheduled sessions and the written Q&A channel. - Completion of assignments or exam answers on your behalf. - Physical lab equipment. If you want help designing a lab, see the Home Lab Blueprint. ## The outcome After eight weeks you will have worked through the major exam topics with hands-on practice, built a reusable lab, sharpened your subnetting and troubleshooting, and developed a study habit you can sustain. Most importantly, you will understand why networks behave the way they do, which is what makes the difference in interviews and on the job. Questions about whether the program fits your level? Contact us before you enroll. --- # Service: Home Lab Blueprint & Build Consultation URL: https://roadtoneteng.com/product/home-lab-blueprint/ Price: from $149 USD A good home lab is one of the best investments you can make in a networking career, but it is easy to waste money on loud, power-hungry equipment you do not need, or to build something that does not support what you actually want to learn. The Home Lab Blueprint & Build Consultation gives you a personalized, practical plan before you spend a cent. ## Overview Every learner has different goals and constraints. Someone studying for the CCNA in a small apartment needs a very different lab from someone exploring automation, firewalls and virtualization in a spare room. Online advice is often contradictory, outdated or biased toward particular products. This service cuts through the noise. You tell us what you want to learn, how much you want to spend, how much space, noise and power you can tolerate, and what hardware you already have. We design a lab that fits, explain every recommendation and give you a clear build plan. It is a personalized version of the approach in our free guide to building a home network lab. ## Who it is for - CCNA candidates who want a lab that covers the exam topics efficiently. - Network and system administrators who want a safe place to test changes before production. - Learners interested in firewalls, routing protocols, network automation or monitoring. - Anyone with a box of second-hand equipment who is not sure how to turn it into a useful lab. - People with limited space, budget or tolerance for noise who still want hands-on practice. ## What is included - Goals and constraints review: a detailed questionnaire covering learning goals, budget, space, noise, power, existing hardware and computer specifications. - Lab approach recommendation: a clear recommendation for a virtual, physical or hybrid lab, with the reasoning and trade-offs explained. - Software guidance: suitable simulation, emulation and virtualization platforms for your goals, including free options where appropriate. - Equipment list: a vendor-neutral list of recommended equipment with what to look for when buying new or used, and what to avoid. - Starter topology: a diagram of your initial lab, with a clean addressing plan and VLAN layout you can extend. - Build checklist: step-by-step instructions to set up the lab, connect to it safely and isolate it from your home network. - First-lab exercises: a short set of starter exercises to verify the lab works and get you practicing straight away. - Growth path: suggestions for how to expand the lab later as your skills grow. ### Deliverables - A written lab blueprint (PDF and editable document). - A topology diagram in an editable format. - An equipment and software list with buying notes. - A build checklist and starter exercises. - A 45-minute live consultation call and 7 days of email follow-up. ## Process and timeline The blueprint is usually delivered within 3 to 5 business days of receiving your completed questionnaire. - Questionnaire: after checkout, you receive and complete a short questionnaire about your goals, budget and setup. - Design (days 1–3): we design your lab and prepare the blueprint, diagram and checklist. - Delivery (days 3–5): you receive the written blueprint and a link to book your consultation call. - Consultation: a 45-minute video call to walk through the plan, answer questions and adjust recommendations if needed. ## What we need from you - A completed questionnaire with honest answers about budget and constraints. - Specifications of the computer you plan to use for virtual labs, such as processor, memory and storage. - A list of any networking equipment you already own, with model numbers if possible. - Your learning goals, such as a target certification, a job role or specific technologies. Do not buy anything before your blueprint arrives. Many learners find they need less hardware than they expected, and the right choices can save significant money and noise. ## What is not included - Equipment, software licenses or subscriptions, which you purchase yourself. - Hands-on configuration of your lab devices or remote building of the lab for you. - Ongoing tutoring or study support. For structured mentoring, see the 1:1 CCNA Mentorship Program. - Design of production home or business networks. For businesses, see the Small Business Network Setup. - Guidance on obtaining software images or licenses outside their vendors' terms. We only recommend legitimate sources. ## The outcome You will have a clear, confident plan for a lab that fits your goals, budget and living space, plus a starter topology and exercises to begin practicing right away. Instead of researching equipment for weeks, you can spend that time actually configuring, breaking and fixing networks, which is where real learning happens. Not sure if this is the right starting point? Read our FAQ or contact us. --- # Service: Network Documentation & Diagram Package URL: https://roadtoneteng.com/product/network-documentation-package/ Price: from $350 USD If the only complete map of your network lives in one person's head, or in a diagram drawn years ago that no longer matches reality, you are one departure or outage away from serious trouble. The Network Documentation & Diagram Package gives you accurate, professional documentation of the network you actually have, in formats your team can keep up to date. ## Overview Good documentation is one of the most valuable and most neglected parts of any network. It shortens troubleshooting, makes changes safer, supports security reviews and insurance questionnaires, and allows a new administrator or IT provider to become effective quickly. Yet most small networks have little more than a sticky note with the router password. In this engagement we discover and record your network from the devices themselves, rather than relying on memory or old drawings. We then turn that information into clear diagrams and structured reference documents following the approach described in our network documentation guide. Everything is delivered in editable formats so you can maintain it as your network changes. ## Who it is for - Businesses with little or no existing network documentation. - Organizations changing IT providers or onboarding a new administrator. - Teams preparing for a security review, cyber insurance application or audit that asks for network diagrams. - IT generalists who know their network but never had time to write it down. - Businesses planning upgrades or moves that need an accurate starting point. ## What is included The standard scope covers a single site with up to 25 network devices, including routers, firewalls, switches and wireless access points or controllers. - Discovery: remote collection of device details, neighbor relationships, interface status, VLANs, routing and addressing using read-only access or supervised sessions. - Logical diagram: networks, VLANs, subnets, gateways, routing and security zones, showing how traffic flows. - Physical diagram: devices, interconnections, uplinks and key port connections, based on discovery data and information from your on-site contact. - Device inventory: make, model, serial number where available, firmware version, management address, location and role of each device. - Port map: switch port assignments, VLAN membership and descriptions for in-scope switches. - IP and VLAN register: every subnet and VLAN with purpose, gateway, DHCP ranges and reserved addresses. - Configuration backups: current configurations exported and stored with the documentation. - Key settings summary: internet service details, DNS, DHCP, NTP, remote access and management access methods, recorded without storing passwords in the documents. ### Deliverables - Logical and physical network diagrams in editable format and PDF. - A network reference document summarizing the environment. - Spreadsheets for the device inventory, port map and IP and VLAN register. - A folder of configuration backups. - A short list of observations, such as undocumented devices or inconsistencies, noticed during discovery. - A 45-minute handover call and 14 days of email follow-up. ## Process and timeline Most documentation packages are completed within 1 to 2 weeks. - Intake and kickoff: you complete a questionnaire and we agree secure read-only access, preferred formats and a contact for on-site questions. - Discovery (days 1–4): we collect information from each device and confirm physical details with your on-site contact. - Drafting (days 4–7): we produce diagrams, inventories and registers. - Review (days 7–9): you review a draft, and we resolve any questions or gaps. - Handover (days 9–10): final documentation is delivered and explained on the handover call. For security, we never record passwords or secret keys in documentation. We recommend storing credentials separately in a password manager and rotating any shared during the engagement. ## What we need from you - Read-only or temporary access to in-scope devices, or a person who can run commands during supervised sessions. - An on-site contact who can answer questions about cabling, rack locations and labeling, and take photos if needed. - Any existing diagrams, spreadsheets or notes, however old. - Your preferred documentation tools or formats, if you have them. ## What is not included - Configuration changes or fixes. Observations are reported, not implemented. - Physical cable tracing, labeling or on-site surveys. - Documentation of servers, endpoints, applications or cloud services beyond network connectivity. - Ongoing documentation maintenance after handover. - Networks larger than the standard scope or with multiple sites, unless agreed in writing. ## The outcome You will have a complete, accurate and editable picture of your network that anyone on your team, or any future provider, can understand. Troubleshooting becomes faster, changes become safer and handovers become far less stressful. To act on any issues discovered along the way, consider a Network Health Assessment or Firewall & Security Hardening. Have a question about scope or formats? Contact us before ordering. --- # About Us URL: https://roadtoneteng.com/about-us/ Network Admin Journey began with a simple idea captured in our tagline, "Connecting Networks Innovatively": if you learn something about networking the hard way, write it down clearly so the next person can learn it the easy way. What started as a personal, public record of moving from network administration toward network engineering has grown into a practical knowledge hub and a small consulting and mentoring practice. ## Our story Most network engineers do not start out designing routing architectures. They start by resetting switch ports, chasing a printer that dropped off the network, replacing a failed access point, or figuring out why "the internet is slow" on a Monday morning. That is network administration: keeping things running, often with limited documentation, limited budget and very little time to step back and ask why the network was built the way it was. The road from that day-to-day work to network engineering is less about a single certificate and more about a change in thinking. An administrator asks, "How do I fix this?" An engineer also asks, "Why did this happen, how do I prevent it, and how should this network be designed so it scales?" Making that shift requires fundamentals, deliberate practice, good habits and a lot of patient troubleshooting. Network Admin Journey was created to share that journey in public. Instead of keeping notes in a private notebook, the lessons were written up as guides: how subnetting actually works, why VLANs matter, how routing protocols make decisions, how to build a lab that lets you break things safely, and how to troubleshoot methodically rather than by guesswork. The goal was never to look impressive. It was to be useful to the person who is exactly where we once were. You can read the longer version of that philosophy in our article The Road from Network Admin to Network Engineer. Over time, readers started asking for more than articles. Small businesses asked for help applying the same principles to their own offices. Learners asked for structured guidance and accountability while preparing for exams or a career change. That is how the consulting and mentoring side of Network Admin Journey came about: as a natural extension of the same work, done with the same care. ## Our mission Our mission is to make networking understandable, practical and secure for the people who depend on it, whether that is a learner building their first lab or a small business that simply needs its network to work reliably. In practice, that means three things: - Explain clearly. Networking has a reputation for jargon. We believe almost any concept can be explained in plain language without losing accuracy. - Teach through practice. Reading is a start, but real understanding comes from configuring, testing, breaking and fixing things in a safe environment. - Leave things better documented than we found them. Every engagement and every guide should leave the reader or client with something they can keep using after we are gone. ## What we do Network Admin Journey has two connected sides: free learning resources that anyone can use, and paid services for people and organizations who want hands-on help. ### Free guides, tools and roadmap Our blog publishes long-form guides on core networking topics, from subnetting and VLANs to OSPF, BGP, IPv6, monitoring and automation. Our network tools page offers interactive helpers for everyday tasks such as subnet calculations. The learning roadmap lays out a sensible order for building skills, so you spend less time wondering what to study next and more time actually studying it. These resources are free to read and use. We fund them through the services described below, not through paywalls. ### Consulting for small and mid-sized businesses Many small organizations run networks that grew one device at a time. They work, mostly, until they do not. Our consulting services are designed for exactly that situation: assessing what you have, setting things up properly, hardening security and documenting the result. Engagements are delivered remotely by default, with on-site work available only by separate agreement. You can browse the full list on our services page. ### Mentoring for aspiring network engineers For learners, we offer structured one-to-one mentoring and lab design consultations. Mentoring is not about handing out answers. It is about helping you build a study rhythm, design effective labs, understand the concepts behind exam topics and develop the troubleshooting mindset that employers actually value. ## Our values and principles Everything we publish and every service we deliver follows a small set of principles. They are the habits that helped us grow, and they are the habits we try to pass on. Lab-first We test ideas in a lab before recommending them. Configuration examples in our guides are meant to be reproduced, and changes we propose for client networks are reasoned through and, where practical, validated before they touch production. If you want to start your own, our guide to building a home network lab is a good place to begin. Document everything A network that only one person understands is a risk. We write down what we find, what we change and why. Every paid engagement ends with documentation you own. Our network documentation guide explains the approach in detail. Security by default Security is not an add-on at the end of a project. Strong credentials, least privilege, segmentation, up-to-date firmware and sensible logging are part of how we design and configure from the start. Our firewall hardening checklist reflects that mindset. Plain language We explain what we are doing and why, in terms that make sense to the person paying for it or learning from it. If a recommendation cannot be explained clearly, it probably needs more thought. Vendor-neutral We do not sell hardware and we are not tied to any manufacturer. We recommend what fits your needs, budget and skills, and we are happy to work with the equipment you already have whenever it is reasonable to do so. ## How we work Whether you are a business ordering an assessment or a learner joining a mentorship program, our process follows the same basic shape: - Listen first. We start by understanding your situation, goals and constraints. For services, that usually begins with a short intake questionnaire after you place an order or contact us. - Gather facts. We review what exists today: devices, configurations, topology, pain points or, for learners, your current knowledge and study habits. We prefer evidence over assumptions. - Plan and agree. We propose a clear plan with scope, timeline and deliverables, and we confirm it with you before any change is made. - Do the work carefully. Changes are made methodically, with rollback options where relevant. Mentoring sessions follow a structured plan with hands-on lab work. - Document and hand over. You receive written findings, diagrams, configuration notes or study materials, depending on the service, so the value remains with you. - Follow up. Each service includes a defined period for questions and clarifications after delivery, as described on the individual product pages. All services are delivered remotely by default using secure screen sharing, video calls and shared documents. On-site work is only available where explicitly agreed in writing. ## Who we help Our free resources are for anyone curious about networking. Our services are aimed at a few specific groups: - Small and mid-sized businesses without a dedicated network team, such as offices, clinics, studios, retail locations and nonprofits, that need a reliable, secure network and clear documentation. - Solo IT generalists and system administrators who look after the network alongside everything else and want a second pair of eyes or a structured improvement plan. - Aspiring network engineers preparing for certifications such as the CCNA, or moving from help desk or administration roles into networking. - Home lab enthusiasts who want to build a practical lab environment without wasting money on the wrong equipment. If you are not sure whether we are a good fit, ask us. We would rather tell you honestly that a different kind of provider suits you better than sell you something you do not need. ## What makes us different There are many places to learn networking and many IT providers. Here is what we believe sets Network Admin Journey apart: - Teaching is built into every service. We explain our reasoning so you understand your own network, not just receive a bill. - Fixed, published prices. Each service has a clearly stated price and scope on its product page, so you know what you are paying for before you check out. - Documentation you keep. Diagrams, findings and configuration notes are delivered in standard formats you can open and edit without proprietary software. - Practical over theoretical. Our recommendations are prioritized by impact and effort, so a small team can actually act on them. - Consistent with what we publish. The methods we use with clients are the same ones we explain openly in our free guides. You can read how we think before you ever pay us. ## Our commitments to you Trust is earned, so we prefer to make commitments we can keep rather than claims we cannot verify. Here is what you can expect: - Honesty about scope. If something falls outside a service, we will say so and explain your options rather than quietly expanding the bill. - No invented credentials or testimonials. We do not publish fake reviews, inflated statistics or made-up client stories. Our work and our writing should speak for themselves. - Respect for your data and systems. We request only the access we need, use it only for the agreed work, and recommend that you rotate any credentials shared with us once the engagement ends. See our privacy policy for details. - Accurate, reviewed content. Our guides are written to be correct and are updated when we find errors or when technology changes. Our editorial policy explains how. - Clear terms. Our terms and conditions and refund policy are written to be read, not hidden. - Accessibility. We aim to make our website usable by as many people as possible. Our accessibility statement explains our approach and how to report problems. ## Ready to take the next step? If you are learning, start with the learning roadmap and our free guides. If you need hands-on help with a business network or want structured mentoring, explore our services or get in touch with your questions. You can also reach us directly at contact@roadtoneteng.com. Explore our services Contact us --- # FAQ URL: https://roadtoneteng.com/faq/ Below you will find answers to the questions we are asked most often about Network Admin Journey, from our free learning resources to our consulting and mentoring services, how ordering works, and how we protect your information. Select a question to expand its answer. If you cannot find what you are looking for, please contact us or email contact@roadtoneteng.com. You may also find it helpful to read about us or browse our services. ## General What is Network Admin Journey?Network Admin Journey is a practical networking knowledge hub and a small consulting and mentoring practice. We publish free long-form guides, interactive network tools and a learning roadmap, and we offer paid services for small and mid-sized businesses and for people building a career in networking. It all grew out of a public, documented journey from network administrator to network engineer. Are your guides and tools really free?Yes. Our articles, network tools and learning roadmap are free to read and use, with no account and no paywall. They are supported by our paid consulting and mentoring services rather than by locking content away. If a guide helps you, the best thanks is sharing it with someone else who is learning or telling us where it could be clearer. Do you work with clients outside the United States?Yes. Our services are delivered remotely, so we can work with clients worldwide as long as we can find workable meeting times across time zones. Prices are listed in US dollars, and our payment processors handle currency conversion where applicable. On-site work is only available by separate written agreement and depends on location. Are you affiliated with Cisco or any other vendor?No. We are vendor-neutral and independent. We may reference specific products, certifications or command syntax because they are widely used and useful for learning, but we do not sell hardware and we are not paid to recommend any manufacturer. Trademarks mentioned on the site belong to their respective owners. How do I contact you?The easiest way is the form on our contact page, or you can email us at contact@roadtoneteng.com. Tell us briefly what you need, whether that is a service question, a correction to a guide or a general enquiry, and we will reply as soon as we reasonably can, usually within a few business days. Can I suggest a topic or report a mistake in a guide?Please do. We want our content to be accurate and useful. Send corrections or topic ideas through the contact page, ideally with a link to the article and a short note on what you found. Our editorial policy explains how we review and update content. ## Services & Pricing What services do you offer?We currently offer six fixed-scope services: a Network Health Assessment, Small Business Network Setup, Firewall and Security Hardening, a Network Documentation and Diagram Package, a Home Lab Blueprint and Build Consultation, and a 1:1 CCNA Mentorship Program. Each has its own page with scope, timeline and deliverables, and you can compare them all on our services page. How much do your services cost?Each service has a fixed starting price shown on its product page and on the services overview. Prices range from the Home Lab Blueprint at the low end to the Small Business Network Setup at the high end. If your environment is larger or more complex than the standard scope, we will tell you before any extra work begins and agree on any change in writing. Which service should I start with?If you are a business and not sure where your network stands, the Network Health Assessment is usually the best first step because it gives you a prioritized list of findings. If you already know you need a new or rebuilt network, start with the Small Business Network Setup. Learners usually start with the mentorship program or the home lab blueprint. Do you work on-site?Our services are delivered remotely by default using secure screen sharing, video calls and shared documents. Some engagements, such as the Small Business Network Setup, can include optional on-site work, but only by separate agreement covering location, travel and any additional costs. Many tasks can be done remotely with the help of someone on your premises. Do you sell or supply hardware?No. We do not resell equipment. We can recommend suitable hardware, write a vendor-neutral bill of materials and help you compare options, but you purchase devices directly from the supplier of your choice. This keeps our advice independent and means you own your equipment and warranties outright. Can you work with the equipment I already have?In most cases, yes. We work with common business-grade routers, firewalls, switches and wireless systems. If a device is end-of-life, no longer receives security updates or simply cannot do what you need, we will explain why and suggest alternatives, but we never recommend replacement just for the sake of it. ## Mentorship & Learning How does the CCNA mentorship program work?The 1:1 CCNA Mentorship Program runs for eight weeks with live online sessions. We start with a skills assessment, build a personal study plan, and then work through exam topics with hands-on lab assignments, review sessions and troubleshooting practice. Between sessions you can send questions in writing. Do you guarantee that I will pass the exam?No, and you should be cautious of anyone who does. Exam results depend on your preparation, practice time and performance on the day. What we can promise is a structured plan, honest feedback on your weak areas and plenty of practical lab work so you understand the material rather than memorizing it. What equipment do I need for mentorship or a home lab?For most CCNA-level study you can start with free or low-cost network simulation and emulation software on a reasonably modern computer. Physical equipment is optional. The Home Lab Blueprint service helps you choose the right mix of virtual and physical gear for your goals and budget. Our guide to building a home network lab is a good free starting point. I am a complete beginner. Is mentoring right for me?Mentoring works best once you have covered basic concepts such as IP addressing and how a LAN works. If you are brand new, start with our free learning roadmap and guides such as Subnetting Made Simple. When you are comfortable with the fundamentals, mentoring can help you accelerate and stay accountable. Can I reschedule a mentoring session?Yes, with reasonable notice. Please let us know as early as possible if you need to move a session, ideally at least 24 hours in advance. Sessions missed without notice may not be rescheduled. The exact arrangements are confirmed when we agree your session schedule at the start of the program. ## Orders & Payments How do I place an order?Choose a service from the shop or services page, add it to your cart and complete checkout. Checkout is handled by WooCommerce. After your order is confirmed, we email you a short intake questionnaire so we can understand your environment or goals and schedule the work. What payment methods do you accept?Payments are processed securely through our payment processors via the WooCommerce checkout, which may include card payments and PayPal depending on your location. We never see or store your full card details. Available methods are shown at checkout. When does work start after I pay?We aim to contact you within a few business days of your order to send the intake questionnaire and agree a start date. The stated duration of each service begins once we have received the information and any access we need. If your timing is urgent, mention it in your order notes and we will tell you honestly whether we can meet it. Can I get a refund?Refund eligibility depends on whether work has started and how much has been delivered. Our refund policy explains the details, including cancellations before work begins and what happens if we cannot deliver as agreed. If something is not right, contact us first, because we would rather fix it. Do you provide invoices or receipts?Yes. You receive an order confirmation by email after checkout, and you can view your orders at any time in My Account. If you need specific details added for your business records, such as a company name or tax identifier, let us know when you order. ## Privacy & Security How do you handle access to my network?We ask only for the access needed for the agreed work, and we prefer temporary accounts with the minimum necessary privileges or supervised screen-sharing sessions. We never ask you to send passwords over plain email. When the engagement ends, we recommend that you remove our accounts and rotate any credentials that were shared. Will you keep my configuration files and network details confidential?Yes. Information about your network, including configurations, diagrams and findings, is used only to deliver the service you ordered. We do not publish client details, and any example we write about in a guide is generic or fully anonymized. See our privacy policy and terms and conditions for more detail. What personal data does the website collect?We collect the information you choose to give us through forms and checkout, plus limited technical data needed to run and secure the site. Our security plugin, Wordfence, may log IP addresses to protect against attacks. The privacy policy describes what we collect, why, how long we keep it and your rights under laws such as the GDPR and CCPA/CPRA. Do you use cookies or analytics?We use essential cookies needed for the site, cart and checkout to work. Analytics cookies are only set if you consent through the cookie banner, which is managed by CookieYes. You can change your choice at any time. Our cookie policy lists the categories in detail. How can I access or delete my personal data?Contact us at contact@roadtoneteng.com with your request. Depending on where you live, you may have the right to access, correct, delete or export your personal data and to object to certain processing. We may need to verify your identity before acting on a request, and some records, such as order data, may need to be kept for legal or accounting reasons. ## Still have questions? Every situation is a little different. If your question is not covered here, send us a short message describing what you need and we will point you in the right direction, even if that means recommending a different kind of provider. Contact us View services