Q: 4
Refer to the exhibit, which contains a partial command output.
The administrator has configured BGP on FortiGate. The status of this new BGP configuration is
shown in the exhibit.
What configuration must the administrator consider next?
The administrator has configured BGP on FortiGate. The status of this new BGP configuration is
shown in the exhibit.
What configuration must the administrator consider next?Options
Discussion
Option D since eBGP by default doesn't allow multihop. Here the peer isn't directly connected, so enabling ebgp-enforce-multihop should fix it. Pretty common BGP issue on FortiGates, but let me know if I'm missing a detail.
C/D? I don't think it's B, since usually the AS is already set if you're seeing this neighbor. But C is a trap-enabling BGP on the remote side won't fix multihop issues. Pretty sure D is needed because the neighbor isn't directly connected, unless I'm missing something in the output. Open to other takes if someone sees a config detail I missed.
B or maybe A. If the local AS isn’t set to 65300, you’ll never get a session up with a remote peer expecting that, and FortiGate won’t initiate BGP correctly. Also, missing a static route could cause neighbor reachability problems even before worrying about multihop settings. I think those are higher priority than enabling ebgp-enforce-multihop in some setups. Anyone else run into this edge case and needed to fix routing/AS first?
D gets my vote. Since eBGP only forms with directly connected peers unless ebgp-enforce-multihop is on, and the neighbor IP looks like it's not directly connected, enabling that should allow sessions to form. Pretty sure that's it. Disagree?
Honestly, Fortinet's BGP setup quirks are such a pain sometimes. D imo
Be respectful. No spam.
