An engineer has configured a new Remote Networks connection using BGP for route advertisements. The IPSec tunnel has been established, but the BGP peer is not up. Which two elements must the engineer validate to solve the issue? (Choose two.)
With the IPSec tunnel already established, the underlying transport connectivity is confirmed to be working correctly, which narrows the troubleshooting focus specifically to the BGP session parameters themselves rather than network reachability. Two configuration values are the most common and immediate causes of a BGP peer failing to come up even over a healthy tunnel: the MD5 authentication secret, if BGP authentication is enabled on either side, must match exactly between Prisma Access and the customer ' s CPE, since any mismatch causes the peer session to be silently rejected during the initial OPEN message exchange, matching option A. Equally critical is the Peer AS Number — if the AS number configured on either the Prisma Access side or the CPE side does not match what the other side expects for that specific peering relationship, the BGP session will never successfully establish, regardless of how correctly every other setting is configured, matching option C. MRAI (Minimum Route Advertisement Interval) timers, referenced in option B, govern how frequently route updates are sent once a BGP session is already established and exchanging routes — they have no bearing on whether the initial peer session comes up in the first place, making them irrelevant to this specific symptom. The Advertise Default Route checkbox (option D) controls whether Prisma Access advertises a 0.0.0.0/0 route once peering is functional; it is a route-advertisement behavior setting, not a prerequisite for the BGP peer session itself to establish.
Chosen Answer:
This is a voting comment (?). You can switch to a simple comment. It is better to Upvote an existing comment if you don't have anything to add.
Submit