How to Configure BGP Peering Over a Site-to-Site IPSec VPN?
Short answer
C Peer ASN: 64515 -
Question
Key Takeaways
This question tests the fundamental distinction between local and remote BGP parameters, with the primary trap being the accidental entry of the local ASN into the peer ASN field.
Configuring BGP over a site-to-site IPSec cloud VPN requires explicitly defining the remote peer's IP address and Autonomous System Number. The certification community unanimously agrees that the peer ASN must strictly match the customer's provided ASN, not the local router's identifier.
Common mistake: Candidates frequently select an option using the local ASN (64515) for the peer ASN, which violates eBGP peering rules and prevents session establishment due to AS path validation failures.
Expert Analysis
Why the Answer Is Correct
BGP peering relies on accurate neighbor identification, requiring the remote device's IP (169.254.11.2) and its specific Autonomous System Number (64517) to establish an eBGP session. Link-local addresses in the 169.254.0.0/16 range are standard for point-to-point tunnel interfaces, making them ideal for BGP neighbors without consuming public IP space. Associating the Cloud Router with the tunnel handles IPsec phase 2 traffic, but BGP requires manual neighbor definition under the routing policy.
Why the Other Options Are Wrong
Selecting the local ASN (64515) as the peer ASN incorrectly configures the session as iBGP, triggering loop-prevention mechanisms that immediately drop the connection. Options suggesting incorrect peer IPs would fail the TCP handshake on port 179, while mismatched authentication settings would cause MD5/TCP-AO negotiation failures. Since the question explicitly provides the customer's peer ASN, any deviation breaks the peering adjacency.
Community Comment Notes
The candidate community strongly validates option C, with multiple users confirming that the peer ASN must represent the remote side's configuration. Comment [1] explicitly clarifies that 'the peer ASN should be the local ASN on the other side,' reinforcing the bidirectional nature of BGP parameters. Consensus remains absolute across all votes, indicating this is a straightforward parameter-mapping exercise rather than a complex troubleshooting scenario.
Official Reference
- https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/configure-networking/configure-routing-features/configure-bgp-configuration/configure-a-cloud-router-for-bgp-over-sites-to-site-vpn-tunnels
- https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/configure-networking/configure-routing-features/configure-bgp-configuration/configure-bgp-neighbors
- RFC 4271 Section 8 (BGP Peering State Machine)
These links open the official vendor documentation in a new tab.
Exam Strategy
Always map the 'peer' fields to the remote device's exact specifications before committing BGP configurations. Verify that your local ASN differs from the peer ASN when designing eBGP topologies, and remember that tunnel interface IPs directly serve as BGP neighbor addresses in site-to-site deployments.
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
09bd94b 👍 2 Answered CShouldn't be 'C' ? the peer ASN should be the local ASN on the other side
-
1f01b87 👍 2 Answered CC is the correct answer
-
RKS_2021 👍 1 Answered CC is the correct answer.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All PCNE Questions
Access 80 questions with complete answers and detailed explanations.
View Full PCNE Practice Test →