A DR-site Data Domain sits across the campus, and replication for it will not be configured until next month's DR project begins. What is the sensible scope for today's basic connectivity testing regarding that peer?

Basic bring-up testing exists to prove the paths the design says will exist, and a designated replication peer is one of them: checking that the peer's address resolves and answers from the replication interface, with latency inside the design's expectation, validates VLANs, routing, and the firewall posture of the actual port group replication will use. Done today, a gap becomes a punch-list item with a month of runway; done next month, it is a stalled project with a change-request trail. Limiting today's scope to management reachability quietly assumes the replication network is a separate, different path - which is usually the whole reason it has its own VLAN - so the untested assumption is precisely the expensive one. Configuring then deleting a live replication relationship manufactures risk the schedule did not ask for: replication state, unscheduled data movement, and removal that is never quite as clean as promised, all to obtain a fact ping-shaped tests already provide. A saturation study is capacity engineering, not basic connectivity testing, and flooding a shared campus link during another team's business hours is how a bring-up test becomes an incident. Exam caveat: record the firewall ports the replication will need for the future project rather than opening them early. Operational check: peer reachable from the replication interface with latency logged against the design expectation, and the result filed on the acceptance sheet.