During commissioning of a branch-office Data Domain you plan replication to the DR appliance at head office. The management interface is configured with the branch LAN's address and netmask and the branch's default gateway, yet the head-office target subnet is only reachable through a different router that the branch gateway does not know about. The target is up and its firewall permits the traffic, but a ping from the appliance console to the target fails while a laptop on the same LAN succeeds. What should the network configuration phase have included?
Select an answer to reveal the explanation.
Short Explanation
Think of your appliance like a laptop on your desk: a correct address and mask don't teach it where head office lives. Its gateway is its map, and if the map doesn't point that way, add a static route for that subnet and prove it with a ping before you ever touch replication settings. Here's the trap: the replication config looks broken when really the network configuration underneath it was never finished.
Full Explanation
Reaching any non-local subnet is a routing question, and an appliance forwards off-subnet traffic solely toward its configured default gateway. When the intended replication target sits behind a router the branch gateway does not know, the appliance has no path to it no matter how correct the address and netmask are, so a static route naming the proper next hop, or a corrected default gateway, belongs in the network configuration task, followed by reachability tests such as ping and traceroute from the console to every planned peer. The peer-trust explanation fails because trust settings govern replication acceptance on the target, not the return path of ICMP from a source that never had an outbound route in the first place. The dedicated-interface claim also fails: even on platforms where replication data can use a separate interface, the console ping tests this interface's own routing table, and a failed ping to a planned target is a real defect, not expected noise. Suspecting the target service misreads the evidence, because the laptop's success proves the path exists for a host that has proper routing, not for the appliance that does not. Exam caveat: routes configured during commissioning should be confirmed persistent after a save or restart. Operational check: from the appliance console, ping and traceroute the replication target, then begin the replication configuration only after both succeed.