350-401 Practice Question: Router bgp 65000 bgp router-id 10.0.0.1 neighbor…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  This is an iBGP session because the remote AS matches the local AS.

  Why this is correct

  The session is classified as iBGP because the neighbor's configured remote-as matches the local autonomous system number (ASN). In BGP, the sole criterion for declaring a session internal is that both peers belong to the same AS; the neighbor can be any reachable IP address, even across subnets. Since the remote-as is equal to the local AS, the BGP state machine treats it as an internal session, which affects attributes like next-hop handling and loop prevention. This is the fundamental rule that distinguishes iBGP from eBGP.

• ✗

  This is an eBGP session because the neighbor IP is in a different subnet.

  Why it's wrong here

  The premise that eBGP requires a different subnet is incorrect; the distinction between iBGP and eBGP is based exclusively on AS numbers, not subnet topology. A BGP session is eBGP only when the remote-as is different from the local AS, regardless of whether the neighbor IP is on the same or different subnet. In practice, eBGP peers often are directly connected on a shared subnet, but they can also be multihop across a routed network. Therefore, the neighbor being in a different subnet does not make this session eBGP.

• ✗

  The router will automatically set next-hop-self for routes sent to this neighbor.

  Why it's wrong here

  Cisco routers do not automatically apply 'next-hop-self' to routes advertised to iBGP peers; it is a per-neighbor configuration option. By default, the next-hop attribute of an iBGP-learned or eBGP-learned route is preserved when advertising to an internal peer, which can leave an unreachable next hop if the peer has no route to it. The 'next-hop-self' command must be explicitly configured on the neighbor statement to change the next hop to the local router's address. Thus, this behavior is far from automatic, making the statement false.

• ✗

  The configuration is invalid because iBGP requires a loopback interface.

  Why it's wrong here

  iBGP does not mandate loopback interfaces; it only requires that the TCP connection between peers can be established, and that can use any reachable IP address. Loopback interfaces are commonly recommended for iBGP to ensure the session stays up even if a physical interface fails, but they are not a prerequisite. A configuration using a physical interface is valid as long as the remote-as matches the local AS and IP connectivity exists. Therefore, the configuration is not invalid solely because no loopback is used.

Go deeper

Related to this question