Overlapping 10/8 Across Three Business Units and Two Data Centers
Your employer, a manufacturing group, has acquired three companies that all use 10.0.0.0/8 without coordination. The group now has 14,000 users at 42 sites, two data centers (DC-A and DC-B), and a shared services block for DNS, AD, and SAP. Each DC has a FortiGate 1800F active-passive pair with 2x10 Gbps internet links; branches use FortiGate 60F/100F and a carrier MPLS L3VPN with static routing only to the CE. Business units must remain isolated, yet all must reach shared services and each DC must be able to serve the other's sites during a DC outage. Today all internet traffic backhauls to DC-A, adding 90 ms for Office 365 and creating a single point of failure. The CISO requires deep inspection of general internet traffic but accepts certificate-only inspection for Microsoft 365. You are asked for a target design that keeps overlapping address space working and removes DC-A as the choke point.
1. Design the VDOM and routing model that supports overlapping 10.0.0.0/8 address space, shared services, and DC redundancy. Explain how routes are exchanged and where policy is enforced.
Read the worked answer
Treat each business unit as a separate routing domain, not as a subnet. At each DC, create tenant VDOMs (BU-A, BU-B, BU-C), a shared-services VDOM, an internet VDOM, and a DC-transit VDOM. Each tenant VDOM gets an inter-VDOM link (/30) to shared services and to internet; shared services advertises a unique 172.16.0.0/16 summary into each tenant via BGP or static. Because FortiGate BGP is per-VDOM, give every VDOM a unique loopback and peer tenant VDOMs with the MPLS PE in the tenant VRF; branches keep static defaults to the CE, and the CE maps each branch to the correct VRF. Tenant-to-tenant traffic must not leak; only shared services is imported. For DC redundancy, build an iBGP session between DC-A and DC-B transit VDOMs over DCI/MPLS; originate tenant summaries with BGP communities and use route-maps so a tenant route is imported only into the matching tenant VDOM and shared services. Put DIA in the internet VDOM; tenant default routes point to it; use central NAT with per-tenant SNAT pools so return traffic and logging stay attributable. This keeps overlapping prefixes separated and gives each DC a path to every tenant.
2. Where should deep inspection and certificate-only inspection run, and how do you justify the performance and latency tradeoff?
Read the worked answer
Place deep inspection where the horsepower and policy ownership are, not where users are. The 1800F pair at each DC has CP9/NP7 capacity; branch 60F/100F cannot deep-inspect 1 Gbps without severe throughput loss. Therefore keep general HTTPS deep inspection in the DC internet VDOM, but split the policy: Microsoft 365 traffic gets certificate-only inspection (SNI/category based) and is steered to the nearest DC using BGP local preference on the branch's MPLS path; all other HTTPS gets deep inspection. The CISO's DLP requirement is met because the traffic still traverses a DC FortiGate; only the inspection depth changes. If Office 365 latency still exceeds 40 ms for a region, add local DIA at the branch only for M365 with certificate inspection, but size the branch FortiGate for encrypted throughput and keep logging via FortiAnalyzer. Do not put a full deep-inspection profile on the branch and assume the 100F will handle it; SSL inspection throughput is the limiting number, not firewall throughput. This is a risk-based split: full inspection for unknown or general traffic, metadata-based policy for a trusted SaaS tenant.
3. How do you prevent asymmetric routing when both DCs can serve internet traffic and branch sites, and what should happen during a planned DC maintenance window?
Read the worked answer
Asymmetry is a design failure, not a CLI toggle. Ensure a branch's outbound and return path use the same DC by making the DC choice deterministic: advertise tenant summaries from DC-A with lower local preference or a shorter AS path; prepend on DC-B; do not run active-active anycast for stateful traffic unless you can keep flow affinity. On the branch, the static default to the CE follows the MPLS route to the preferred DC. For inbound internet, use per-DC public NAT pools and DNS/GSLB to send a user to one DC; SNAT then ties the return flow to the same DC. If a flow does cross DCs, FortiGate will drop it with asymmetric routing disabled, which is the safer default. Do not enable asymroute globally to hide the problem; it weakens stateful inspection. For planned DC maintenance, drain the DC by withdrawing or prepending routes, wait for BGP convergence, then fail over. Test with diagnose sniffer packet on both DCs and get router info bgp to prove the forward and return path. If the business insists on active-active, the application must be designed for it, not merely the firewall.