Ferry terminal staff are building a simple point-to-point GRE overlay and must set tunnel endpoints correctly. What roles do the tunnel source and destination play?
Select an answer to reveal the explanation.
Short Explanation
Source and destination on a GRE tunnel are like the ferry's departure dock address and the arrival dock address on the public road system—the underlay path that carries the sealed trucks. They are not MACs inside the cargo hold or VRF name stickers.
Full Explanation
Ferry terminal staff building a simple point-to-point GRE overlay must set tunnel endpoints as underlay addresses. The tunnel source is the local underlay IP used to originate GRE-encapsulated packets, and the tunnel destination is the remote peer's underlay address that receives them. Those two addresses define where the ferry terminal GRE packets enter and leave the underlay path; overlay addressing rides inside the encapsulated payload separately. Tunnel source and destination are not Layer 2 MAC addresses learned only via ARP inside the overlay—GRE endpoints are IP underlay identifiers, not overlay MACs. The source is not always 0.0.0.0 with destination fixed to the OSPF router ID regardless of underlay; operators choose reachable underlay addresses appropriate to the peer path. Tunnel source does not identify the VRF name string while destination identifies the VNI number; VRF and VNI are separate virtualization constructs, not GRE endpoint fields. Exam caveat: source and destination must be reachable across the underlay and consistent on both peers (each side's destination matches the other's source); asymmetric or unroutable endpoints yield a tunnel that never truly passes traffic. Operational check: configure matching underlay source/destination on both ferry GRE peers, confirm underlay ping between those addresses, bring the tunnel interface up/up, and verify overlay reachability only after underlay endpoint connectivity is proven.