Hello everyone, I am new in this forum and glad to join such a knowledgeable community. I am working mostly with small and medium networks using MikroTik routers, and I often see how important proper planning is before configuring anything. Things like understanding topology, traffic flow, IP structure, and future expansion really help to avoid problems later. In many cases, I first try to visualize the network on paper or diagram software before touching RouterOS settings. This reminds me of how other technical fields work, where planning documents are essential, like blueprint estimation used in construction to understand requirements before starting work. In networking, if the planning is weak, even strong hardware cannot fix design mistakes. I would like to know how other members here usually plan their networks before deployment and what tools or methods you find most effective when working with MikroTik devices.
Don't disagree planning is important, and often missed step. But requirements come before a network layout. So whether you're talking about a single house, apartment complex, factory, coffeeshop, etc... all start with a few different requirements. As these may dictate the amount and type of planning requirement.
Now more generally, I still think the OSI 7-layer model is still best framework for thinking about networks. So you should have plans organized around the layers. For example, like a cabling plan (Layer 1-2), IP numbering plan (Layer 3-4), network services (Layer 5-7). Much like a house has a plan for the structural/framing, electrical/plumbing/mechanical, and cabinets/fixtures/interior.
Mainly spreadsheets...
And using monitoring system once deployment starts, since often good monitoring is more useful long-term, than referencing documents that tend to not get updated
In planning specifically, I guess I focus on IP numbering plans... we strive to keep IP subnets unique, even across customers, so it forms a kinda unique identifiers, and can be used locate what customer/site/device is at issue. And clarity in subnets make using routing protocol easier. With the subnets are oranziged around 10..<site/vlan>.x scheme, with 172.y.x.x being used links between routers and VPNs.
To a fair extent, that is where is starts - with the physical layout of the site and some physical constraints on where cables can run. And then you start thinking about where data is flowing - you identify places where it goes from servers in outbuilding 1 to the master switch in the main building and back down the same cable to workstations in that same outbuilding 1. And you decide between living with it, routing the data differently or doubling up on cable.
The order of planning is not rigid in my view. I assemble each of these plan components alongside one another. It is scalable, and broadly agrees with Amm0’s suggestion of using the OSI stack as a framework.
I start with a top view which is simply coloured blobs with arrows showing what traffic has rights to flow where between networks (no devices in plan). This will later inform firewall rules.
Then I might switch to the bottom end, which is communications/cabling layout and patch panel, and work up a layout of services and devices. Cabling and wireless options represent constraints on layout. The IP plan is an essential by now, preferably started after the top blob phase.
My tool of choice is Omnigraffle (or equivalent in your environment)*. I wind up with four diagrams: the functional blobs with access arrows; IP plan over a services sketch; physical layout with allocation of devices; patch panel with connections to other access points, wired or otherwise.
Date and version all plans.
Nothing here is special for MIkrotik. My own network is mixed, and I can substitute. When Mikrotik are kind enough to supply an RB5009-type box with 2.5G ports it already has a target spot.
\* Personal bias: in my view a spreadsheet is usually the second best choice for almost anything; wildly over-used because it is there.