City WAN staff configure eBGP multihop toward an ISP even though the neighbor is on the same directly connected subnet. What is the correct ENCOR expectation for that adjacency?
Select an answer to reveal the explanation.
Short Explanation
If the ISP is sitting on the next desk, you don't shout across ten offices — skip multihop. Multihop stretches TTL for non-adjacent eBGP; directly connected peers use the normal adjacent pattern. MST matching and forced GRE aren't the rule here.
Full Explanation
City WAN staff peering eBGP to an ISP on the same directly connected subnet normally do not need eBGP multihop. Multihop raises TTL so eBGP can form across multiple IP hops when neighbors are not adjacent; on a shared interconnect, standard adjacent eBGP TTL behavior is the correct ENCOR expectation. Configuring multihop 'just because' on a directly connected peer is unnecessary and can mask misunderstandings about adjacency.
Calling multihop mandatory for every directly connected eBGP peer is incorrect—adjacent peers are the default enterprise-to-ISP pattern without multihop. Refusing sessions unless MST and OSPF areas match the ISP mixes Layer-2 STP regions and IGP area design into BGP session bring-up; those are not BGP adjacency prerequisites. Requiring GRE before any ISP peer can establish invents an encapsulation dependency BGP does not impose for a normal IP interconnect.
Exam caveat: use ebgp-multihop (or TTL security patterns) when the eBGP neighbor IP is truly multiple hops away (for example loopback peering across an intermediate network). Directly connected interface peering should use the connected addresses and default eBGP TTL. Do not confuse multihop with update-source loopback, which is a related but distinct design choice often paired with multihop for non-adjacent peering.
Operational check: confirm the ISP neighbor address is on the shared subnet, leave multihop disabled, and verify Established state. If someone enabled multihop unnecessarily, remove it after validating adjacency still forms. When true loopback-to-loopback eBGP is required later, then plan multihop/TTL and routing to those loopbacks deliberately rather than by habit on civic edge handoffs.