Title here
Summary here
Network Design Blueprint
On this page
1. List of Infographics
Design Charter; Standards; Soft Skills etc
Wireless Standard
Art of Network Troubleshooting
Healthcare IT Jargon
2. Requirements Gathering for enterprise Network
Sample Questions
These are some sample questionnaires that needs to be asked to customer before vendor can work on Solutions or define Scope of Work (SOW).
General Questions
- Who are the key stakeholders in this deployment?
- What compliances are we trying to meet?
- Any typical pain points in the overall network?
- Growth plan for next 3 years which can impact this project? - additional endpoints, IoT, automation of network, etc
- Network visibility requirements
- Any architectural and security governing guidelines which needs to be met?
- what level of integration is required from network monitoring perspective?
Campus Wired
- What business problems are target to solve. Something from previous deployment?
- Which groups are responsible for the integration and deployment of Campus wired side?
- how many wired endpoints are planned to be connected?
- wired and wireless on same switch stack?
- distribution switches or IDFs
- how many IDFs and MDFs
- what kind of fiber runs from IDFs to MDFs?
- how many wired endpoints be brought into single IDF?
- how many AP connections will be brought into single IDF?
- OOB management for switches?
- Remote console management for switches?
- how many VLANs to be used?
- dedicated voice and data VLAN?
- need for wired guest network?
- need for test/dev network in SDA fabric?
- layer 2 flooding requirements
- are there any silent hosts in the network?
- Do you leverage Virtual Desktops and imaging software for end user PCs and Laptops?
- Do you have any monitoring and/or security scan software that is outside of the fabric that will try and establish connections inside the fabric?
- All endpoints should run DHCP, do you have any devices that do not support DHCP and must be statically assigned IPv4 addresses on the endpoint?
- Does your critical networks require connectivity through the fabric? Can we isolate critical traffic to only a single local fabric edge node?
- Describe your critical client protocols. Are they communicating via Unicast with neighbor discovery, broadcast, L2 multicast, static?
- Are you using PTP (Precision Time Protocol), NTP/SNTP (Network Time Protocol). If so where do the time servers reside?
- Are there any critical network devices that are in the fabric that will require communication to a destination/source outside the fabric?
- What size (endpoint count) are your proposing for VLANs?
- Do you plan on connecting L2 switches to fabric edge ports for extending infrastructure?
- Are there any devices that would require a connection through multiple NIC connections? (MLAG, port-channel, active/standby)
- Please describe you mDNS requirements for devices that will need auto discovery or leverage L2 multicast to establish communications across the fabric.
- multicast requirements for applications or paging systems?
- Any specific AV or tele-conferencing requirements?
- are dual uplinks from all switches a capability with your current fiber runs?
- uplink bandwidth requirements?
- is IPv6 planned to be used in the network?
- Do you have any requirements for L3 gateways to be firewalls for endpoint isolation?
- Diagrams describing your current high level vision for the network
- Diagrams for physical layout of the hospital locations of IDF/MDF closets
- Diagrams for each PLC line with breakdown of any vendor “pods” that will be connected into the fabric.
- List of IP address pools allocated for the sites
- List of VLAN name and number requirements you have
- Hostname standard
- Explain any 3rd party vendors you are planning on integrating with this solution. Example Palo Alto for firewall.
- Proposed VLAN standard, name and numbers
- Golden Config Templates
Campus Wireless
- What are the wireless use cases?
- How many SSIDs are planned to be used? Please list all SSIDs expected to be deployed. Which primary authentication mechanism(s) will be deployed for each SSID? For example: WebAuth, Pre-Shared Key, or 802.1x."
- What are the segmentation requirements for wireless, such as VN, Subnet, and SGTs?
- How each of these SSIDs be authenticated?
- Any captive portal or CWA requirements?
- Where will the Guest Portal be located? ISE, WLC, or Web Server?
- will there be wired guest network in SDA space?
- are there any high-density wireless requirements? If yes, which part of the network?
- is mGig desired?
- outdoor wireless required?
- approximate data throughput in the wireless network?
- desire to use local wireless controllers or centralized controllers?
- Do you need the wireless network to be Fabric enabled or OTT?
- will guest network be offloaded out via local internet or centralized guest anchor controller?
- Are there any current or planned architectural designs or heat maps?
- Can a 20ms latency be achieved between all the APs and the WLC?
- Are there specific RF requirements, such as band, channel, data rate.. etc.?
- Are there any mounting restrictions? AP / antenna mounting
- Is blanket coverage required, or are there areas where coverage is not needed?
- Which RF survey tool, such as Ekahau or Hamina, will be used by the surveyor?
- How many concurrent clients are expected in total, and what is the expected count per use case?
- Is WiFi 6E ( 6 Ghz) Required anywhere?
- Any Mesh requirements ?
- Do you have clients that support single band only?
- Is WPA3 supported by the Clients?
- AVC / QoS Requirements?
- mDNS / Bonjour requirement ?
- will APs use an external DHCP server with option 43 to connect to the WLC?
- Are you going to use tri-radio ?
- Do you have Workgroup bridge in the network ?
- will all the APs be connected to RJ45 and powered up with UPOE?
- Do you have requirements to connect APs via Fiber with DC/AC/Power Injector ?
- What is the estimated total number of endpoints (Mac-Address) that connect to the wireless environment?
- “How would you describe the current scalability of your network and plans for future growth? "
- Please list currently configured RF profiles and highlight any areas where these are necessary.
- Please indicate any security mechanisms used to secure the AP’s wired connection, i.e., 802.1x
- Please indicate if location services are in operation and the designed location accuracy.
- Please indicate if Voice or Video Over WLAN requirements
- What types of wireless client devices will connect to the network? For any known special-purpose devices (tags, barcode scanners, IoT devices, etc.), please list the make and model number and include any device-specific requirements, such as: single band operation, 802.11 technology limitations, specific beaconing rates, etc.
- Are you anticipating persistent WiFi interference or non-WiFi signal noise? If yes, please provide a list of the systems causing interference and the channels affected
- what are the naming and labeling convention ?
- Is there AAA Override requirement?
- is there a location tracking requirements ( wayfinding, real-time tracking, BLE tags, asset tracking)?
- Are wired and wireless networks restricted to separate physical switch stacks ?
- Wi-Fi 6/6E for client access in the OT spaces
- Wireless data traffic should be offloaded to right VRF and VLAN on the switch
- GUEST network should be wireless only network
- No plans on outdoor wireless connectivity
- High-density to be considered in cafeteria, meeting halls and AGV/RGV paths
- is WPA3 required?
- Wireless Clients’ specifications?
- Do you have devices that require static IPs?
- Is there any area with high temperature dust or vibration environment that requires wireless coverage
Security
- Approximately how many NADs (switches/wireless controllers/etc…) using TACACS?
- Will guest wireless be required? Sponsored vs Self Registered?
- What is the backend directory services provider? Onsite MS Active Directory, Azure AD, etc…
- What is your PKI Infrastructure today?
- Load Balancing - Load balancers to be used or redundant RADIUS server config on NADs?
- Will posture for corporate workstations be required? Posture checks for patches, virus DATs, certain files/versions/reg keys/etc….
- Will workstations be MDM managed? If so, which MDM provider?
- Statement - for ISE profiling purposes, highly recommended best practice to use DHCP everywhere for endpoints. For devices that require static IP, use DHCP reservations. Important to stress this point with 3rd party vendors deploying their hardware.
- Which team creates/writes NAC policy requirements?
- Which team would manage NAC (Identity Services Engine, ISE)?
- is zero-trust desired to be implemented in this project or near future?
- will there be local firewalls at the site?
- what networks will terminate on the firewalls?
- which team manages firewalls and security infrastructure?
- Centralized management of firewalls?
- Direct internet requirement from the site?
WAN
- What business problems are target to solve. Something from previous deployment?
- WAN SLAs from the provider?
- WAN connections speed?
- WAN transport types?
- WAN MTU size?
- common WAN for IT and OT?
- how is macro segmentation over WAN addressed today?
- any micro-segmentation requirement over WAN today?
- any multicast requirements over WAN today?
- Where are RPs located?
- what is the approximate size of the routing table today?
- is IPv6 planned to be used in the network?
- is WAN designed to be Active/Active or Active/Standby?
- Any plans for leveraging automation over WAN?
Internet & Cloud
- What business problems are target to solve. Something from previous deployment?
- Dedicated internet connectivity from the site?
- who will access dedicated internet from the site? Guest? corp users?
- speed and transport type of internet circuits?
- any remote access VPN requirements locally to the site?
- will local internet be used for OOB connectivity?
- will local internet be used for any failover connectivity?
- any plans on using LTE/5G based backup links?
- how will cloud be accessed? Locally via internet or dedicated links?
- any firewalls on the cloud based links?
- what clouds are being used actively? - AWS, Azure, GCP?
Applications
- Any critical applications to be mindful of
- application visibility requirements
- any application SLAs from client side?
- what is dominant application traffic flow: north-south or east-west?
- are application servers located in the data center or local?
- where are shared services like DHCP, DNS, IPAM, AD, etc located?
Environmental & HA
- uptime and SLAs
- MTTRs from providers
- HA requirement
- power requirement - redundant utility feeds
- Multiple power supplies in MDF and IDF switches?
- UPS in MDF and IDFs?
- is OOB network planned for this network?
| Symptom | What to check before adding complexity |
|---|---|
| Slow reads | Query efficiency, latency source, and whether cached data can tolerate staleness |
| Write spikes | Whether processing can happen asynchronously; queue capacity and consumer throughput |
| Too much traffic | Backend capacity—a load balancer distributes traffic but doesn’t create capacity |
| Read-heavy database | Replica lag and whether reads require current data |
| Write-heavy database | Query, index, and contention issues before taking on sharding |
| Slow queries | Execution plans; extra indexes also increase write cost |
| Temporary failures | Retry only safe operations, with bounded exponential backoff and jitter |
| Duplicate requests | Idempotency enforced atomically, including concurrent duplicates |
| Symptom or requirement | Design response |
|---|---|
| Links consistently congested | Add capacity; review traffic patterns and oversubscription |
| Voice/video degrades during congestion | Apply end-to-end QoS with consistent classification and queuing |
| One link failure takes down a site | Add redundant paths with independent failure domains |
| Two circuits fail together | Verify carrier, conduit, entrance, and upstream diversity |
| Slow recovery after failures | Tune failure detection and routing convergence; validate application recovery |
| Traffic takes inefficient paths | Review routing policy, summarization, and exit placement |
| Unequal WAN links are poorly utilized | Use application-aware path selection or deliberate traffic engineering |
| Critical applications suffer on the WAN | Measure loss, latency, and jitter; select paths against application needs |
| Routing tables become difficult to manage | Build hierarchical addressing and summarize at appropriate boundaries |
| Large Layer 2 failures affect many users | Reduce broadcast domains and establish clear Layer 3 boundaries |
| Loops cause widespread outages | Minimize Layer 2 scope and apply appropriate loop protections |
| Devices can reach too much | Segment by trust and function; enforce least-privilege policy |
| Unknown devices gain network access | Apply identity-based access control and appropriate onboarding |
| Lateral movement is easy | Enforce segmentation between workloads and endpoint groups |
| Wireless coverage exists but performance is poor | Design for airtime, capacity, interference, and client behavior |
| Roaming interrupts voice or clinical workflows | Validate RF overlap, authentication, and client roaming behavior |
| DNS or DHCP failure disrupts an entire site | Provide resilient services and validate reachability during failures |
| New sites require repeated manual configuration | Standardize designs and automate deployment with validation |
| Changes cause unexpected outages | Use prechecks, staged rollout, postchecks, and a tested rollback |
| Nobody can explain an intermittent issue | Correlate telemetry, flow data, logs, packet captures, and timestamps |
| Observed problem | Architectural response | Tradeoff / hidden failure mode |
|---|---|---|
| Traffic blackholes even though a summary route remains reachable | Align summarization with actual reachability and failure domains; preserve more-specific routes where necessary | An aggregate advertises reachability for space that may be partially unreachable. A discard route prevents loops but does not restore reachability |
| A redundant topology still experiences transient loss during convergence | Analyze the order of FIB updates and resulting microloops; evaluate loop-free repair and ordered convergence where supported | Fast failure detection alone does not make distributed forwarding updates consistent |
| Aggressive BFD creates instability during congestion or CPU stress | Engineer detection intervals against platform behavior, scale, scheduling, and transport characteristics | Faster detection increases sensitivity; a false failure can cause more disruption than the original impairment |
| ECMP paths exist, but one member congests while others remain idle | Evaluate flow entropy, elephant flows, hash inputs, and flow placement | Per-flow hashing balances hashes rather than bytes. Per-packet distribution can introduce reordering |
| Adding a path resets established sessions | Coordinate routing changes with stateful service placement and flow symmetry | A valid return route may bypass the firewall or NAT instance that owns the session |
| A stateful service fails despite symmetric routing at each site | Model symmetry across the complete service chain, including tunnel termination, NAT, and failover | Local symmetry does not guarantee that both directions traverse the same state owner |
| Small packets work; large transfers intermittently hang | Define the encapsulation budget and validate PMTUD across every transport and service insertion | MSS adjustment helps TCP; it does not fix oversized UDP or every encapsulation mismatch |
| Application traffic suffers even though average utilization is low | Investigate microbursts, egress queue occupancy, fan-in, and speed transitions | Average interface counters hide subsecond contention; more buffering may trade drops for latency |
| QoS markings look correct, but critical traffic still drops | Map classification through hardware queues, tunnel markings, policers, and provider treatment | Consistent DSCP values do not guarantee consistent forwarding behavior |
| Overlay health is green while application performance is poor | Correlate overlay probes with underlay forwarding, traffic class, packet size, and actual application paths | Probe traffic may receive different treatment or miss short-lived impairment |
| Remote endpoints remain reachable through stale locations after mobility or failure | Analyze mapping lifetime, invalidation, withdrawal, and control-plane/data-plane convergence together | A healthy underlay cannot correct stale overlay endpoint state |
| Multihoming introduces intermittent duplicate delivery or blackholing | Validate designated-forwarder behavior, split-horizon enforcement, and failure transitions | Steady-state correctness does not prove correctness during role changes or partial failures |
| Segmentation policy is correct locally but fails across domains | Preserve or explicitly translate identity and policy semantics at fabric, WAN, cloud, and firewall boundaries | An identifier may lose meaning or enforcement at a boundary even when IP reachability survives |
| A control-plane outage becomes a forwarding outage hours later | Model retained state, aging timers, reauthentication, new endpoint admission, and restart behavior | Existing sessions surviving proves little about new sessions or long-duration isolation |
| Two redundant devices fail during the same change | Treat software, configuration, controllers, power, and automation as shared failure domains | Physical redundancy offers little protection against a common defect pushed everywhere |
| Failover succeeds in testing but fails during a real outage | Validate surviving capacity and dependencies under the intended failure combinations | Reachability can recover while surviving links, firewalls, NAT pools, or authentication services saturate |
Next
Technical Books