Before arrival, the network team asks what the Data Domain deployment will need in writing. The system must support administrative access, backup traffic, and replication to the DR site. What should the pre-deployment network plan contain?
Select an answer to reveal the explanation.
Short Explanation
You wouldn't ask an electrician to guess where the breaker panel goes. A Data Domain wears several hats—management, service, data, replication—and each hat needs a home: a static address, a VLAN, and a firewall zone, all agreed before the box arrives. Hand the network team that written plan and skip the week-long email chase.
Full Explanation
A Data Domain system presents distinct network functions—management for DMC or ELM administration, service interfaces for support connectivity, data interfaces carrying backup protocols, and a replication path to the DR target—so a pre-deployment plan collects static addressing, VLAN placement, gateways and DNS for each function that will be live, plus the firewall zones the traffic will cross. Written handoff matters because a bring-up without agreed addresses stalls on conflicts, wrong VLANs and mid-install surprises. A single DHCP reservation fails as a plan because named administration, certificates and support integrations expect stable documented addressing, and multiple functions cannot share one address. MAC addresses alone fail because they define placement nowhere, deferring the same conflicts to bring-up day. Placing management on a public address fails the security model, because administration belongs behind the customer's firewall controls on the management network. Exam caveat: Secure Multi-Tenancy designs multiply interface planning, because each context needs its own network resources. Operational check: give the network team a table of function, purpose, VLAN, address, and zone, and get the completed rows back before traveling to site.