IP Addressing and Subnetting Questions

Covers designing and calculating Internet Protocol addressing for networks, including both strategic planning and low level subnetting math. Candidates should be able to design addressing schemes that account for number of hosts, growth, scalability, and segmentation such as virtual local area network addressing, reserve addresses for gateways and infrastructure, and document address plans. Must understand Internet Protocol version 4 and Internet Protocol version 6 addressing models, classful versus classless allocation, subnet masks, classless inter domain routing notation, and how to compute network addresses, broadcast addresses, and usable host ranges. Includes public versus private addressing, address conservation techniques, address aggregation and summarization, considerations for routing and summarization, and operational topics such as static versus dynamic assignment and how addressing choices interact with network services and translation mechanisms.

HardTechnical

79 practiced

Explain how IP addressing design can assist QoS classification and policy-based routing (PBR). Propose a prefix allocation strategy to simplify ACLs and QoS policy application for voice, video, and general data traffic in a campus network, and describe trade-offs with address waste and scalability.

Sample Answer

**Approach / Why addressing helps**Designing IP prefixes by service class lets routers/firewalls match on prefix rather than deep-packet inspection; that makes QoS classification, ACLs and PBR simpler, faster, and more deterministic. Prefix-based matching reduces ACL/PBR rule count and CPU cost.

**Prefix-allocation strategy (example)**- Global campus block: 10.0.0.0/16- Per-building /floor hierarchical plan: - Voice pool: assign a contiguous /24 per building (e.g., 10.B.0.0/24) — all VoIP endpoints use addresses from this pool - Video/UC (conference endpoints): contiguous /24 per building (10.B.1.0/24) - General data: remaining aggregated /22 per building (10.B.4.0/22) split into /26s for access switches- On access switch: use smaller subnets (/28–/26) for port-level control, but preserve upper-layer aggregation so edge routers see service-contiguous prefixes

**How this simplifies QoS/PBR/ACLs**- QoS classification: match source IP prefix -> apply DSCP rewrite or class-map. One rule per service-per-building versus per-IP.- ACLs: write rules like permit ip 10.B.0.0/24 any for voice signaling or RTP; fewer, human-readable rules.- PBR: route voice prefixes to low-latency path or SBC gateway by matching prefix; failover policies by prefix-level next-hops.

**Trade-offs**- Address waste: dedicating /24s may underutilize IPv4 space; mitigations: use smaller per-building voice blocks (e.g., /26) if scale permits; prefer IPv6 where possible.- Scalability: benefit is rule count grows O(buildings) not O(devices). But too fine-grained per-floor/service prefixes increases routing table size and management overhead.- Flexibility vs simplicity: aggregated prefixes ease routing and QoS; very dynamic environments (BYOD) may need identity-based policies or DHCP option tagging instead.

**Operational best practices**- Document naming and allocation, enforce via DHCP reservations or network access control (802.1X).- Combine prefix-based classification with DSCP policing and trust boundaries.- Use route summarization, VRFs, and prefix-lists to control propagation and keep forwarding tables small.

MediumTechnical

44 practiced

You have a private block 10.10.0.0/16 and must design VLSM allocations for these VLANs: Engineering (600 hosts), Guest Wi-Fi (250 hosts), Sales (120), Lab (70), Finance (40), HR (30). Allocate subnets to minimize wasted addresses, reserve addresses for gateways and infrastructure, and explain your allocation order and spare capacity for growth.

HardSystem Design

49 practiced

Design a NAT64/DNS64 solution so IPv6-only internal clients can reach IPv4-only legacy servers. Specify the IPv6 prefix to synthesize IPv4-mapped addresses, where the NAT64 translator and DNS64 resolver are placed, how the mapping works, and considerations for logging, DNSSEC, and applications that embed IPv4 literals.

Sample Answer

**Requirements & constraints**- IPv6-only internal clients must reach IPv4-only legacy servers.- Preserve logging/forensics, handle DNSSEC, and support apps that embed IPv4 literals.

**High-level design**- Deploy DNS64 resolver in the IPv6-only network (or in cloud VPC) to synthesize AAAA records for IPv4-only hostnames.- Deploy NAT64 translator (stateless for scaling? Use stateful NAT64 /64:96 or RFC 6052 mapping) at the network edge where IPv6 traffic leaves to IPv4 space (DMZ or egress VPC gateway).

**Synthesized prefix**- Use an IPv6 prefix from RFC 6052 for IPv4-embedded addresses, e.g. 64:ff9b::/96 for global translation or pick an owned /96 like 2001:db8:cafe:64::/96 for private translation. Ensure consistent prefix in DNS64 and NAT64.

**How mapping works**- DNS64: when AAAA absent, synthesize AAAA = <prefix>::[IPv4 in hex], return to client.- Client connects to synthesized IPv6 → hits NAT64: translator extracts embedded IPv4, creates/uses mapping and forwards to IPv4 server, translating headers and ports (stateful NAT64 maintains state for return traffic).

**Placement & scaling**- DNS64 near clients (reduces latency); NAT64 at egress with load-balancers and autoscaling translators. Use anycast for DNS64; scale NAT64 horizontally with consistent prefix assignment.

**Logging & observability**- Log DNS64 syntheses (queries, synthesized AAAA, client). Log NAT64 translations (src/dst IPv6, mapped IPv4, timestamps, ports). Correlate DNS and NAT logs via query IDs, timestamps, client IPs for forensics.

**DNSSEC considerations**- DNSSEC-signed zones: DNS64 cannot re-sign responses. Options: - Use DNS64 only for unsigned zones. - Implement DNS64 that fetches DNSKEY and returns synthesized AAAA while signaling AD bit cleared; better: use a proxy that performs validation and use DNS64-aware stubs or application-layer fallback.- Document limitations and prefer application-level test.

**Apps embedding IPv4 literals**- IPv4 literals won’t be resolved by DNS64; clients must hit NAT64 via IPv6 literal mapping: - Provide DNS64-synthesized AAAA for special DNS name that maps to IPv4 literal. - Configure DNS64 prefix and advertise to apps; use a proxy (HTTP/HTTPS) or dual-stack gateway to handle literal IPs. - For hard-coded IPv4 addresses, implement outbound proxy or use SIIT-DC / stateless translation with routing of 64:ff9b::/96 into NAT64.

**Tradeoffs & security**- Stateful NAT64 preserves ports but requires scaling and tracking. Stateless (SIIT) simplifies logs but requires globally routable prefix plan.- Firewall rules must translate and inspect; consider ALGs and TLS implications.- Test with DNSSEC, IPv6-only clients, and applications that embed IPs; document known failure modes.

HardSystem Design

49 practiced

Design an IP addressing and segmentation scheme for a high-security environment that must separate PCI, HR, Dev/Test, and Production systems. Specify VLAN/subnet masks for each zone, firewall zone boundaries, management VRFs, gateway addresses, and strategies to minimize lateral movement and blast radius while keeping operations manageable.

Sample Answer

**Clarify goals & constraints**- Separate PCI, HR, Dev/Test, Production; minimize lateral movement; manageable operations; high security/compliance (PCI DSS).

**High-level plan**- Strong layer-2 segmentation (VLANs/PVLAN), VRF for management, NGFW-enforced layer-3 boundaries, host-based microsegmentation and NAC, explicit allow-listing, bastion/jump hosts and centralized logging.

**VLANs / Subnets / Gateways**- PCI: VLAN 10 — 10.10.10.0/24 — GW (HSRP) 10.10.10.1 - HR: VLAN 20 — 10.10.20.0/24 — GW (HSRP) 10.10.20.1 - Dev/Test: VLAN 30 — 10.10.30.0/24 — GW (HSRP) 10.10.30.1 - Production: VLAN 40 — 10.10.40.0/23 — GW (HSRP) 10.10.40.1 - DMZ (external-facing): VLAN 50 — 10.10.50.0/24 — GW 10.10.50.1 - Management VRF: VRF-MGMT — 192.168.254.0/24 — GW 192.168.254.1 (devices, jump hosts, monitoring)

Use /24s to simplify ACLs and limit blast radius; Prod gets /23 for scale if needed.

**VRFs & Gateway design**- VRF-MGMT isolates management plane; management networks never routed into tenant VRFs except via controlled firewall policies and jump hosts.- Use HSRP/VRRP for gateway redundancy; assign virtual IPs above.

**Firewall zone boundaries & policies**- Zones: pci-zone, prod-zone, dev-zone, hr-zone, dmz-zone, mgmt-zone.- Default deny; allow minimal flows: - pci-zone → mgmt-zone only for monitoring/patching via bastion + jumpbox; no direct inbound from dev/prod/hr. - prod-zone → dev-zone: denied except specific CI/CD egress IPs over TLS to a narrow API port. - hr-zone → prod/pci: deny. - dmz → prod: allow only application-specific ports to hardened app-proxies.- Use stateful NGFW with threat prevention, TLS inspection for approved flows, and identity-aware rules where possible.

**Minimize lateral movement / blast radius**- Private VLANs (promiscuous/isolated) inside PCI to prevent east-west host-to-host.- Microsegmentation: host-based firewalls (OS-level) with centralized policy (e.g., Windows GPO, Linux iptables/Firewalld, or endpoint security).- NAC / 802.1X for port/device authentication; posture checks before network admission.- Jump hosts/bastions in VRF-MGMT with MFA, session recording, and just-in-time (JIT) access.- Limit management protocols (SSH/RDP) to mgmt-zone via jump hosts; disable direct management from non-mgmt networks.

**Operational controls**- Centralized logging (SIEM) and flow collection (NetFlow/IPFIX), syslog segregated into VRF-MGMT collector reachable only from firewalls.- Change control & IaC for network policies (config as code); automated tests in Dev/Test that mirror Prod segmentation.- Regular segmentation reviews, micro-audit of ACLs, and periodic pentests.

**Trade-offs & scalability**- Strict segmentation increases policy count; mitigate with policy groups, tags, and identity-based rules.- VRF for tenant isolation increases control but needs route-target management for required limited routing (route-leaking via firewall/router).

This scheme enforces least privilege, isolates management, and layers network + host controls to reduce lateral movement while keeping operations manageable through automation, role-based access, and centralized logging.

MediumBehavioral

58 practiced

Tell me about a time you led a large IP renumbering or addressing change. Describe the planning steps you took, how you coordinated stakeholders (network, security, applications), risk and rollback planning, tools used (IPAM, automation), and lessons learned. Structure your answer using the STAR method (Situation, Task, Action, Result).

Sample Answer

**Situation** At my previous company we migrated a 3,000-host VLAN from a legacy RFC1918 range to a new structured /16 to remove overlaps with a partner network and support multi-cloud connectivity. The environment included on‑prem servers, cloud VPNs, firewalls, and several application teams.

**Task** I was the lead network engineer responsible for planning and executing the renumbering with zero business‑critical downtime and clear rollback paths.

**Action** - Stakeholder coordination: ran kickoff with network, security, cloud, app owners, and Change Control. Mapped dependencies and published a runbook and contact matrix. - Planning: inventoryed IPs in IPAM (Infoblox), created target addressing plan with subnets, NAT rules, and ACL changes. Created a phased schedule by service criticality. - Automation & tooling: wrote Ansible playbooks to update device configs, DHCP scopes, and host records in IPAM; used Terraform for cloud route updates; developed test scripts to validate reachability and ACL behavior. - Testing: staged changes in lab, then pilot with noncritical services during maintenance window; ran connectivity and performance tests; used packet captures to verify no asymmetric routing. - Risk & rollback: defined per‑phase rollback procedures (restore DHCP scopes, revert ACLs, reapply old routes), kept config backups and automated rollback scripts, and booked rollback windows. Had backout triggers (failed health checks, high error rates). - Change execution: executed in 6 phases over two weekends with real‑time monitoring and coordinated cutover calls.

**Result** Renumbering completed with no critical outages; pilot phase caught two application hard‑coded IPs we fixed quickly. Post‑project, IPAM hygiene improved, automation reduced future renumbering time by ~60%, and I authored a reusable playbook and runbook adopted as team standard.

**Lessons learned** - Early app owner engagement uncovers hard‑coded dependencies. - Automate both forward and rollback paths. - Keep thorough test and monitoring scripts to detect asymmetric routing or policy gaps quickly.

Unlock Full Question Bank

Get access to hundreds of IP Addressing and Subnetting interview questions and detailed answers.

Join thousands of developers preparing for their dream job.